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L Introduction 

This Petition presents two core issues. The first relates to the definition of the legal term 
of art "new matter." The second relates to the authority of PTO employees to disregard the 
PTO's written rules, or to create on-the-fly exceptions. 

The first question presented is, "Did the examiner err in objecting to the 'Amendment 
Accompanying RCE' of April 27, 2005 as 'new matter,' when that amendment adds material that 
is legally defined as not "new matter?" The Examiner makes three errors. First, the Examiner 
disputes the MPEP's, the courts', and the Board's definition of "new matter." There is no need 
for literal support for added material; inherent support for an amendment is entirely sufficient, 
especially where the added material merely states the definition of a term as the term is used in 
the application and is uniformly understood in the art, or states an inherent theory of operation. 
In contrast, the Examiner insists that the only way to avoid the "new matter" prohibition is literal 
support. The Examiner cites no authority for his "literal support" requirement. After his earlier 
papers conceded that "inherent" support was adequate, his later papers simply edit away and 
disregard the portions of the case law that he now finds inconvenient. Contrast Action of 
7/19/05 at 1, lines 14-15 (examiner concedes that "inherent" support is "fundamental") to Action 
of 10/14/05 at 2, lines 19-21 (same quote with "inherent" cropped out). The Examiner's second 
error is to dispute the courts' and Board's instruction against "indiscriminate" reliance on 
dictionaries. The Examiner's reliance on one dictionary, to the exclusion of all others, is 
especially surprising, because the Examiner admits that the dictionary he relies on needs to be 
corrected. Action of 10/14/05 at pp. 4-5. Third, the Examiner's papers present a parade of 
technological errors: as Dr. Levine states in his Declaration (Exhibit L), the Examiner's 
understanding of common terms of art and elementary technological principles is "inadequate, 
unreasonable, and misleadingly overbroad" (Levine Dec. f 8), "demonstrates little 
understanding of basic principles" possessed by all students and practitioners in the art (Levine 
Dec. f 15), "is wrong, both at a technical level, and at the level of careful reading" (Levine 
Dec. f 18), displays "fundamental misunderstanding" (Levine Dec. f 19) and is "impossible" 
(Levine Dec. f 20). 
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The second question presented is "Did the Examiner err by making this first Office 
Action after an RCE final, without examining the application as amended, and without setting 
forth any views on amended claims?" Final rejection is premature because the application has 
not been examined in accord with PTO "present practice." Compliance with and completion of 
"present practice" is a prerequisite for final rejection. MPEP ^ 706.07(a). MPEP § 2163.07(1) 
and 2163.06(1) instruct that an application must be examined as amended, even if the Examiner 
believes that there is some question of new matter. MPEP § 21 1 1 instructs that a claim term 
must be interpreted "consistent with the specification." Examiner Ellis disagrees with both of 
these instructions: he believes that his opinion overrides the specification, even if that renders 
several portions of the specification nonsensical. He disregards the effect of the amendment, 
because he believes it to be new matter. The application has not been examined under the rules. 
Until it has been, final rejection is premature. 

11. The Amendment to the Specification is Not "New Matter" 

A. Petitions Jurisdiction for Question 1 

The Office Action of July 19, 2005 "objects" to an amendment to the specification 
proposed in the "Amendment Accompanying RCE" of April 27, 2005. There is no "new matter" 
or § 1 12 ^ 1 rejection of any claim. Thus, MPEP § 608.04(c) provides that the "objection" is 
reviewable by petition. 

This Petition is timely presented within two months of the examiner's action on 
reconsideration of 10/14/2005. 

B. The Text of the Amendment 

The amendment to which the examiner "objects" is considered sentence-by-sentence in 
§ ILD, starting at page 4. As will be shown below, all of the added language falls into categories 
recognized to be not new matter. 

C. The Legal Definition of The Term of Art "New Matter" 

It is entirely permissible for an amendment to add language to a specification, even 
though there is no literal support. As the courts have noted, "inherent" support is entirely 
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sufficient. In re Wright, 343 F.2d 761, 767, 145 USPQ 182, 188 (CCPA 1965) ("while new 
language has certainly been added, we are not prone to view all new 'language' ipso facto as 
'new matter.' ") The following are NOT new matter: 

• The mere inclusion of dictionary or art recognized definitions known at the time of 
filing an application would not be considered new matter . If there are multiple 
definitions for a term and a definition is added to the application, it must be clear 
from the application as filed that applicant intended a particular definition... 
(MPEP § 2163.07, emphasis added) 

• By disclosing in a patent application a device that inherently performs a function or 
has a property, operates according to a theory or has an advantage, a patent 
application necessarily discloses that function, theory or advantage, even though it 
says nothing explicit concerning it . The application may later be amended to recite 
the function, theory or advantage without introducing prohibited new matter. 
(MPEP § 2163.07(a), emphasis added) 

The Chisum treatise sets out several classes of new language that are not new matter, Chisum, 

Patents § 11.04[2][a] (footnotes omitted, underline added): 

Court decisions state, in various ways, that specifications may be amended 
to "clarify" the original disclosure; thus: (1) "insertion by way of amendment in 
the description .... of a patent application do not invalidate the patent, if they are 
only in amplification and explanation of what was already reasonably indicated to 
be within the invention"; ... (3) ... If the later-submitted material accused of 
being 'new matter' simply clarifies or completes the prior disclosure it cannot be 
treated as 'new matter' ..." (4) "the amendments to the specification merely 
render explicit what had been implicitly disclosed originally, and, while new 
language has certainly been added, we are not prone to view all new 'language' 
ipso facto as 'new matter.'" 

Earlier, the Examiner acknowledged that the "fundamental" test for "new matter" permits 
an amendment that was " inherently contained" in the specification as filed. Action of 7/19/05 at 
1, lines 14-15. He now retracts that position, by editing away the portion of the case that states 
that "inherent" support is the "fundamental" consideration. Contrast Action of 10/14/05 at 2, 
lines 19-21. The examiner then states that he will only allow an amendment that is supported 
explicitly, by: 

"referenc[ing] those portions of the specification which supported this amended material. 
Therefore because applicant failed to point to the portions of the specification which 
support the amended material, there must be no portion of the specification which 
supports the material (otherwise applicant would have simply pointed to that portion) and 
therefore, the material is also new matter. 
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Action of 7/19/05 at 2, lines 1-6; Action of 10/14/05 at f 5. The examiner is confused. 
"Inherency" does not require an explicit statement that can be "pointed to;" "inherency" only 
comes into play when there is no explicit disclosure that could be "referenced." Prima Tek II 
LLC V. Polypap SA.R.L, 412 F.3d 1284, 1289-90, 75 USPQ2d 1219, 1223-24 (Fed. Cir. 2005). 
Because the examiner applies an incorrect legal test, the remainder of his reasoning is irrelevant 
at best. 

D. The Declaration Of Dr. David R. Levine Confirms That The Amendment 
Falls Into Classes Recognized As Not New Matter 

Every sentence of the amendment is either a statement of a legal principle that is an 
inherent rule of patent interpretation, a definition of a technical term drawn from the art that is 
inherent in the very use of the term and the only use in the art that is applicable to this 
application, or an explicit statement of established theories of operation. All of these are well 
established as riot "new matter." 

Dr. Levine (Levine Dec, Exhibit L, f 5) notes that no one in the art could read the 
specification and the terms "process" and "thread" in any way other than discussed in his 
declaration and in the amendment. This statement establishes inherency, by showing that the 
amendment states only matter that is "necessarily" present in the specification as filed, and that 
all other possibilities and probabilities are excluded. 

1. First Sentence 

The first sentence objected to is as follows: 

The terms "process" and *1hread" are used herein in their ordinary and 
customary, though formal, senses, as actually used in the programming 
language systems, operating systems, and processor architecture arts. 

This is merely a restatement of the legal test for "broadest reasonable meaning of the words in 

their ordinary usage as they would be understood by one of ordinary skill in the art." That rule 

of examination is inherent in every patent application. MPEP §§ 2111, 2111.01. It is not new 

matter. 

Dr. Levine (Levine Dec, Exhibit L, 1 27) additionally notes that this sentence merely 
confirms that the term "thread" was used in the specification, even before the amendment, in its 
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customary, though formal, sense. Dr. Levine confirms that this sentence is no more than an 
explicit statement of something that was previously inherent. 

The Examiner has never even attempted to show that this sentence is "new matter." No 
objection exists to this sentence, and none could be raised. 

The Examiner should be overruled with respect to this sentence. 

2. Second and Third Sentences 

The next two sentences of the amendment read as follows: 

Generally, a "process" is a unit of processor scheduling and protection, each with 
an associated data structure (or set of data structures) that, in most 
implementations, holds machine register values and other context associated 
with the process. The process data structures, and thus the processes of a 
computer, are usually under the management of an operating system, usually the 
operating system's scheduler. *^ 

This merely consolidates the art-recognized definition of "process" from The Authoritative 

Dictionary of IEEE Standards Terms (Exhibit A, see also see pages 16-17 of the paper of 

9/15/2005) and the Wikipedia on-line encyclopedia (Exhibit C, see also page 5 of the paper of 

9/15/2005), and the theory of operation for processes described in undergraduate lecture notes 

from the University of California, San Diego, and Carnegie-Mellon University (Exhibits D and 

E, see also pages 8-11 of the paper of 9/15/2005), and the DEC Open VMS description (Exhibit I, 

see pages 12 of the paper of 9/15/2005). Because these sentences merely state the common 

meaning in the specialized art, and the theory of operation, both previously inherent, these 

sentences fall into a class recognized as not "new matter." Wright, 343 F.2d at 767, 145 USPQ 

at 188; MPEP § 2163.07(a) ("The application may later be amended to recite the ... theory ... 

without introducing prohibited new matter.") 

Dr. Levine (Levine Dec, Exhibit L, at 28, 29) confirms that these sentences merely 
state the inherent "understanding in the art" and "theory of operation." 

The Examiner, at most, notes the possible existence of another definition for "process," 
and concludes that stating a definition is "new matter." However, to apply this principle, the 
Examiner bears the burden to make four showings: he must show (a) that there is some 
possibility that his alternative definition could have been the one intended {see MPEP 
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§§ 2163.04, 2163.07(1)), (b) that his alternative definition is "consistent with the specification," 
(MPEP §§ 2111), (c) that his alternative is "consistent with the interpretation that those skilled in 
the art would reach" (MPEP § 21 1 1 .01(11)), and (d) "If extrinsic reference sources, such as 
dictionaries, evidence more than one definition for the term, the intrinsic record must be 
consulted to identify which of the different possible definitions is most consistent with 
applicant's use of the terms" (MPEP §§ 2111.01(n) , 2163.07(1), emphases added). The 
Examiner has been totally silent on all four of these issues, even after specifically challenged on 
them, {e.g.. Amendment of 4/14/05, §§ I.B.3 and LB. 5, at pages 5-6 and 7, noting the 
inconsistency between the Examiner's proposed definition and "the interpretation that those 
skilled in the art would reach," and the inconsistency in the specification under the Examiner's 
hypothesized definition). Without those showings, the Examiner's paper is too incomplete to 
raise any objection at all. The Examiner cannot be affirmed, because there is nothing to affirm. 

Further, as Dr. Levine notes (Levine Dec, Exhibit L, ^ 1 1), the Examiner's supposed 
definition of "process" is "severely flawed," "totally useless," "unreasonable and incorrect." 
Disagreement between the amendment and the Examiner's supposed definition does not suggest 
any deficiency in support for the amendment. 

The second sentence is not "new matter." No objection has even been raised. The 
Examiner should be overruled. 

3. Fourth, Fifth and Sixth Sentences 

The fourth sentence of the amendment reads as follows: 

Generally, a *1hread" is a flow of control within a process. 
This is a direct quote of the ordinary definition of "thread" from the IEEE Dictionary (Exhibit 
A), and thus is not new matter. Prince, 11 USPQ at 481; Kharasch, 67 USPQ at 22. Dr. Levine 
(Levine Dec. 5, 30) confirms that no one in the art would understand any definition that 
conflicts. 

The fifth and sixth sentences read as follows: 

Each thread has an associated data structure (or set of data structures) that, in 
most implementations, hold machine register values (usually different than the 
registers associated with a process) and other context associated with the 
thread. 
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These are merely an explicit statement consolidating the definition of "thread (4)" from the IEEE 
Dictionary and the Microsoft Developer's Network Articles (Exhibits A and F), and the theory of 
operation, as reflected in the UCSD slides and the Carnegie Mellon lecture notes (Exhibits D and 
E, see discussion "thread control block (TCB)"), and section 6.1.1 of the Open VMS description 
(Exhibit I). None of these are new matter. 

The thread data structures, and thus the threads of a process, are usually 
managed either by an operating system or other run time system, to permit the 
thread to be scheduled independently of and concurrently with other threads of 
the same process. 

This is merely a statement of theory of operation from the Carnegie Mellon lecture notes 
(Exhibit E, sections "Kernel Threads" and "User Level Threads"). It is not "new matter." 

Dr. Levine (Levine Dec, Exhibit L, H 5, 10, 30, 31, 32) confirms that no one in the art 
would apply a "broadest reasonable interpretation" that is inconsistent with these three sentences, 
and that the Examiner's view is "unreasonable and incorrect" and that the definition he relies on 
is "simplistic and overbroad" and "fails to convey any useful informadon." The Examiner's 
position is "inconsistent with the use in the specification" (Levine Dec. f 13). Disagreement 
between the amendment and the Examiner's "blind allegiance to the Microsoft Dictionary ... and 
[his] uncritical adoption of definitions that anyone of ordinary skill in the art would recognize as 
unreasonable over-simplifications" (Levine Dec. f 22) does not suggest any deficiency in 
support for the amendment. 

The Examiner's position on these sentences has the same defect as discussed above: four 
showings were required, and none were even attempted. The Examiner's papers are insufficient 
to raise any objection - there is nothing to affirm. 

The Examiner should be overruled. 

4. Definitions Are Given Greater Leeway When There Is No Alternative 
Term Available 

Statements of ordinary meaning are given special deference when there is no reasonable 
alternative to the term at issue. Kliarasch, 67 USPQ at 22 ("It seems impossible to find a term 
that would be of the exact scope ... It is our view that applicant is entitled ... to employ the 
simple broad term 'catalyst'" as supplemented by the definition added by amendment). 
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Here, though repeatedly challenged to do so, the examiner does not dispute that there is 
no other term in the art that has the same range of meanings as the formal sense of the term 
"thread." (Response of April 14, 2005 at 7). As Dr. Levine confirms (Levine Dec, Exhibit L, 
f 14), if the meaning of the word "thread" is distorted as the Examiner proposes, there is no 
opportunity to claim an invention that is fully disclosed as required by § 1 12 1 and 2. 

Under Kharasch, the addition of a definition is not "new matter." 

The examiner's "new matter" objection should be reversed. 

E. The Examiner's Position Is Unsupported By Substantial Evidence 

The Examiner can only be affirmed if his view is supported by "substantial evidence." 
Dixon V. Dept, of Transportation, 8 F.3d 798, 804 (Fed. Cir. 1993). "Substantial evidence" is 
"more than a mere scintilla." Id. A federal decision-maker must "[take] into account 

contradictory evidence or evidence from which conflicting inferences could be drawn The 

substantiality of evidence must take into account whatever in the record fairly detracts from its 
weight." Id "[F]actors such as ... inherent improbability, self-contradiction, omissions in a 
purportedly complete account, imprecision, and errors detract from the weight of that particular 
evidence." Id., quotations omitted. 

In July 2005, in a portion of a decision joined by eleven of the twelve judges of the 
Federal Circuit, the Court warned against over-reliance on informal definitions, even if those 
informal definitions are drawn from a technical dictionary: 

Indiscriminate reliance on definitions found in dictionaries can often produce 
absurd results. ... Even technical dictionaries or treatises, under certain 
circumstances, may suffer from some of these deficiencies. ... 

Finally, the authors of dictionaries or treatises may simplify ideas to communicate 
them most effectively to the public and may thus choose a meaning that is not 
pertinent to the understanding of particular claim language. ... 

Phillips V. AWH Corp., 415 F.3d 1303, 1322, 75 USPQ2d 1321, 1333 (Fed. Cir. 2005) (en banc) 

(citations and quotations omitted, underline added). Dictionaries are not infallible. 

The examiner's basis for his "new matter" objection is that the description added by the 

amendment conflicts with a definition that the Examiner extrapolates from the Microsoft 
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Computer dictionary. An examiner is simply not permitted to indiscriminately rely on one 
dictionary, and ignore all evidence that contradicts his view, as has occurred here. 

Dr. Levine almost echoes the Federal Circuit's Dixon test for lack of "substantial 
evidence," noting that Examiner Ellis' comments are not only "inherently improbable," they are 
"impossible," (Levine Dec, Exhibit L, \ 20), "self-contradictory" (Levine Dec. % 12), they omit - 
considerations of facts (Levine Dec. \ 9), reflect imprecise reading (Levine Dec. \ 18), and are 
"unreasonable and incorrect" (Levine Dec. 1 10). The Examiner cannot be affirmed on the 
current evidence. 

The Examiner himself has cited at least two dictionaries, and this Applicant's papers have 
cited nearly a dozen more sources, that demonstrate that the one definition on which the 
Examiner chiefly relies is simply wrong. No federal employee may simply ignore contradictory 
evidence the way the Examiner has here - he must at least make some attempt to explain away 
the contradiction between his one piece of evidence and every other. Without substantial 
evidence, and an explanation of all other evidence, the Examiner's view is too incomplete to be 
affirmed. 

Further, the Examiner himself concedes that the Microsoft Computer Dictionary needs to 
be corrected, Action of 10/14/2005 \ 9. Yet, even after acknowledging that it is wrong, the 
Examiner continues to rely on it. This suggests something beyond innocent error. 

The portions of the Microsoft Dictionary on which the examiner relies are clearly 
informal. Even a cursory comparison of the Microsoft definitions cited by the examiner reveal 
that they are only informal definitions, barely above the level of a "general usage" dictionary - 
they reflect none of the characteristics that specialists actually use and rely on. The Microsoft 
definition of "thread" states that a thread is merely "part of a process, without explaining any of 
the relevant differences and relationships. The Microsoft definition of "process" never mentions 
the essential attribute of a "process," its "address space." Microsoft itself discourages precise 
reliance on its dictionary: both the notes on the back of the current edition of the Dictionary and 
the Introduction state that the audience for the Microsoft Computer Dictionary is "users" and 
"home users," but does not mention specialists in programming language systems, operating 
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systems, and processor architecture. The back of the Microsoft Dictionary makes clear that 
many of its definitions are over-simplified as a concession to a non-specialist audience: 

You get simple, concise definitions for understanding even the most arcane 
terms.. 

Compare Phillips, 415 F.3d at 1322, 75 USPQ2d at 1333 (discouraging reliance on "simplified" 
definitions). 

When Microsoft writes to specialists in the art, and intends for them to rely on its 
descriptions, Microsoft sets out its definitions much more precisely, as set forth in Exhibit F (see 
more detailed discussion at pages 1 1-2 of the paper of 9/15/2005). In this case, Microsoft's 
formal documentation gives a much more precise definition of the term "thread," demonstrating 
that the definition in the Microsoft Dictionary is not intended to be relied on for precise meaning. 

The examiner has been repeatedly challenged to identify any basis to believe that his 
extrapolation is even correct, let alone "reasonable," or "consistent with the interpretation those 
skilled in the art would reach." Response of 4/27/05 at 17; Response of 3/30/05 at 6-7. By his 
silence, his failure to rebut the uniform definitions set forth in every other source, and his failure 
to explain away the absurd consequences of his extrapolation (see Response of 4/27/05 at page 
18 and the Response of 3/30/05 at 7), he confesses that his extrapolation is outside the scope of 
permitted "broadest reasonable interpretation consistent with the specification" and inconsistent 
with "the meaning given to the term by those of ordinary skill in the art," as required by MPEP 
§2111.01. 

The Examiner has not come forward with "substantial evidence." Any discrepancy 
between the amendment and insubstantial evidence has no legal consequence. The amendment 
is not "new matter." The objection should be reversed. 

III. Final Rejection is Premature 

Paragraph 10 of the Office Action states that the July 2005 Action is final. This is 
premature. 
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A. Petitions Jurisdiction for Question 2 

The Federal Circuit*, the Board of Appeals, and the Director have all held that petition to 
the Director under Rule 181 is the appropriate avenue request review of premature final 
rejection, when finality violates PTO rules, and the only relief requested is reopening of 
prosecution. 

Where the sole relief requested is reopening of prosecution, and the legal basis for relief 
originates in rules promulgated by Patent Office, instead of the statute enacted by Congress - as 
in question 2 of this petition - an issue is petitionable, even if the issue may involve 
consideration of the merits. In re Oku, 25 USPQ2d 1 155, 1 157 (Comm'r Pats and TM 1992) 

(emphasis supplied): 

The designation of a new ground of rejection, while involving a consideration of 
the merits , also involves the important question of whether the Board followed PTO 
regulations established by the [Director].... 

A decision to reopen prosecution ... is a question solely within the discretion of 
the [Director] and is in no wav a review of a merits decision . . . 

Finally, issues are petitionable when "the rules specify that the matter is to be ... 
reviewed by the Director." 37 C.F.R. § 1.181(a)(2). The relevant rule is MPEP § 706.07(c), 
which instructs as follows: 

706.07(c) Final Rejection, Premature 

Any question as to prematureness of a final rejection ... is purely a question of practice, 
wholly distinct from the tenability of the rejection. . . . It is reviewable by petition under 
37 CFR 1.181 . See MPEP § 1002.02(c). 

Question 2 is within § 1.181(a)(2). 

B. Examination Remains Incomplete: Amendments to the Claims of April 27, 
2005 Prevent First Action Final 

The RCE of 4/27/05 was accompanied by an amendment to the claims. The Examiner's 
papers of 7/19/2005 and 10/14/2005 do not reflect that these amendments were even noticed by 
the Examiner, let alone considered. 



* In re Alappat, 33 F.3d. 1527, 1580, 31 USPQ2d 1545, 1588 (Fed. Cir. 1994) {en banc) (Plager, 
J., concurring) (*The [Director] has an obligation to ensure that all parts of the agency ... conform to 
official policy of the agency. . ."); see also Star Fruits 5.MC v. United States, 393 F.3d 1277, 1284-85, 
73 USPQ2d 1409, 1414-15 (Fed. Cir. 2005) ("petition process [is] the 'exclusive administrative check' on 
the discretion of examiners," to ensure that examiners act within the PTO's rules). 



Petition re "New Matter' and Premature Finality 
This paper dated December 14, 2005 



11 114596-28-000053BS S/N 09/626,325 

3040925.3 



Application Serial No. 09/626325 

Attorney Docket No. 1 14596-28-000053BS 

Petition re "New Matter" and Premature Finality of December 14, 2005 

First, amendment to the claims renders first-action-final rejection premature. MPEP 
§ 706.07(b). 

Second, the Examiner's position is now unclear. Does the Examiner consider the new 
claims to be identical in scope to the old claims, or is there some difference? Because the 
Examiner is silent on the amended claims, no clear issue is developed for appeal. 

Final rejection is premature. 

C. The Application Has Not Been Examined - No Issue Has Been Developed 
For Appeal 

In the paragraph spanning pages 2-3 of the Office Action of July 19, 2005, the examiner 
states that he gives no weight to the amendment to the specification because it is new matter. He 
then states that he examines the claims as if the amendment were already cancelled. 

This is a breach of procedural instructions by the Director of the PTO, and is not 
permitted. The MPEP repeatedly instructs that - as a matter of examination procedure - the 
application must be examined as amended, even if the examiner beHeves "new matter" might be 
involved, MPEP §§ 2143.03, MPEP § 2163.06(1), 2163.07. Even giving the examiner the 
greatest possible benefit of the doubt on the broadest reasonable definition of the term "thread" 
in absence of any definition in the specification, MPEP § 2163.07(1) and 2163.06(1) cover the 
facts here, and instruct that the application must now be examined under the definition stated 
(underline added, citations omitted): 

The mere inclusion of dictionary or art recognized definitions known at the time of filing 
an application would not be considered new matter . If there are multiple definitions for a 
term and a definition is added to the application , it must be clear from the application as 
filed that applicant intended a particular definition, in order to avoid an issue of new 
matter and/or lack of written description. . . . 

. . . The examiner should still consider the subject matter added to the claim in making 
rejections based on prior art since the new matter rejection may be overcome by 
applicant. 

Here, even Examiner Ellis does not dispute that the description of "threads" and "processes" 
added to the specification reflects the "particular definition" used in the application as filed. He 
offers no basis (and certainly none based on any written authority) on which to excuse himself 
from the Director's instructions. 
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Finality should be withdrawn, so that the application can be examined for the first time, 
giving full weight to the definition stated in the specification and the "broadest reasonable 
meaning of the words in their ordinary usage as they would be understood by one of ordinary 
skill in the art /' as expressed in every dictionary that purports to state a definition for specialists 
in the art, MPEP § 21 1 1.01, and as now made clear in the specification. 

On the record as it stands, no clear issue is developed for appeal - are the claims to be 
interpreted on appeal "consistently with the specification," or under the examiner's imagined 
definition, with the amendment ignored? Final rejection is premature. MPEP § 706.07. 

When an agency employee acts short of "requirements of the applicable departmental 
regulations," then the employee's action is "illegal and of no effect." Vitarelli v. Seaton, 359 
U.S. 535, 545 (1959). The examiner's disregard of the amendment to the specification departs 
from agency procedures. Thus, as a matter of law, there is no rejection of this application, let 
alone final. Finality should be withdrawn so that the examiner will have an opportunity to 
examine the application. 

D. Examination Remains Incomplete: An Information Disclosure Statement 
Was Not Timely Considered 

The RCE filing of April 27, 2005 requested consideration of the Infomiation Disclosure 
Statement submitted November 9, 2004. The IDS was not timely considered. An application 
may not be finally rejected before "present practice" has been completed. See MPEP § 706.07(a) 
(final rejection is only authorized when all requirements of "present practice" have been timely 
met). 

In this and several other applications, the Examiner has repeatedly changed positions, 
applied new portions of references, reinterpreted claim language, considered IDS's, etc. after 
"final" rejection, and has expressed no opinion on a number of claim limitations until final or 
post-final Actions, while closing the door against any opportunity to respond to his new grounds 
of rejection. See 09/385,394, Petition of April 8, 2005. This is a violation of PTO rules, and a 
violation of the "fairness" that is at the heart of final rejection practice. MPEP § 706.07. The 
PTO cannot apply a double standard. 35 U.S.C. § 3(a)(2)(A) (those who act on behalf of the 
Director must do so "in a fair, impartial, and equitable manner," that is, with bilateral equity. 
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including with respect to examination under § 131). If the Examiner's work is not complete and 
timely, and he has to alter his position or complete his work, then finality is premature, and 
prosecution may not be closed against an applicant.. 

IV. Conclusion 

The "new matter" objection should be reversed. "Finality" of the Office Action of July 
19, 2005 should be reversed, and the examiner instructed to apply the definition set forth in the 
specification and the dictionaries cited above. (To avoid any doubt, this Petition does not request 
any adjudication on the ultimate merits of any claim, only the failure of the examiner to comply 
with procedural requirements for examination.) 



This petition occasions no fee. Kindly charge any additional fee, or credit any surplus, to 
Deposit Account No. 23-2405, Order No. 114596-28-000053BS. 



Respectfully submitted, 



WILLKIE FARR & GALLAGHER LLP 



Dated: December 14, 2005 
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problem 

probe placcmciu is dctci^incd by th^ 

circuit topology. (SCC2d) 1445-1998 

problem S<e:> benchmark pioblem. 

problem board In an analog computer, a rcmovaMe frame of 
receptacles for patch cords and plugs tfiat offers a means for 
mterconnectmg the inputs and outputs of computiiig ele- 
ments. See also: patch board; patch panel 

(Q 6miO-1994w. 165 1977w 
problem check (analog computer) One or more tests used to 
assist m obtammg the correct machine solution to a problem. 
Static check consists of one or more tests of computing ele- 
ments, theu mtercpnnections. or both, perforrned under static 
condiuons- Dynamic check consists of one or more tests of 
computing elcmchts. Acir interconnections, or both, per- 
formed under dynamic conditions. Rate test is a test that ver- 
ifies tfiat the lime constants of the integrators are tfiose se- 
- Icctcd- This term also refers to the computcr^nlrol state that 
miplemcnts the rate lest previously described. Dynamic prob- 
lem check IS any dynamic check used to ascertain tfic correct 
performance of some or all of the computer compoDcnls. See 
also: contputer-conlrol state. (Q 165-1977^ 

Problem Descriptor System (PDS^laGen) A prpgramming 
language useful in a wide variety of operations research aph 
pUcations. and designed to faciUtate the generation of matti- 
CCS and reports for mathematical programming systems. 

(Q 6I0,13-1993w 

problem domain A set of similar problems that occur in an 
environment and lend, themselves to common solutions; x 

(C/SE) 1362-1998 

problcm-oriented language (1) (computers) A programming 
language designed for the convenient expression of a given 

""t^^^^' P>- (20] 

m (software) A programming language designed for the so- 
luaon of a given class of problems. Exarnplcs are list pro- 
ocssmg languages, information retrieval languages. Simula- 
tion languages. (Q 610.12-1990. 610.13-1993w 

problem state In the operation of a computer system, a state in 
which programs other than the supervisory pro^ara can ex- 
ecute. Synonyms: user state; slave state. Contrast: supervisor 

(Q 610.12-1990 

problem variable 5€<r: scale factor. 

procedural cohesion (software) A type of cohesion in which 
the tasks performed by a software module ^ contribute to,a 
given program proceduie. such as an iteration or decision 
process. Contrast: Icnywral cohesion; logical oohestoo; se- 
quential cohesion; coincidental cohesion; functional oAe- 
sion; conununicatioiial cohesion. (Q 610.12-1990 

prtHx^ural mterface (PI) The set of C fimctioas used % an 
appU^on and a delay and power calculation module 

(Ui'lJVI) to exchange mformaiioa and detent 
calculation for a design. (cyDA) 1481-1999 

procedural interface ftmctioa One of die C functions tfaatcom- 
pnse the DPCS procedural interface. - ' (C/DA) 1481-1999 
procedural language (1) (software) A progcanuning language 
m which the user states a j^>ecific set of instnictions thJ^ 
computer must perform in a given sequence. All widely-used 
programmmg languages are of this type. Synonym.' pioct^ 
d^O'e-pnented language. Contrast: nonprocedural language. 
S;ee also: algebraic language; list pioccssing language; logic 
programrhmg language; algorirfunic la^^ ' ' " 

fix A 610.12-1990 
W A computer language in which the user states a OT^c 
setof m^riKtions diat the computer must perform in a giVen 
se^icncc. Examples include BASIC, GOBOL, TORTRAN 
andP^scaL^y/io/iym: prooedure^aiiiid language. Contrast' 
ntiryroccdural language. (Q ^I0.13-I993w 

t^rocediiral programming language (software unit testing) A 
.«w^>u£er programimng language , used to express the se^ 
qiictioc of c^Kaations to be pafoiiaisd t>y a computer (for 
. e«mplc. <»BOL), See also: oonprxx^dural proC^ 

(QSE) IOoSt^ 
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procedure (1) (computers) The course of action tak«i for. the 
soluuon of a problem. (q pO). (85J. 

W (nuclear power quality assurance) A document that 
specifics or describes how an activity is to be performed* . 

n\ fAWc^ft ^A • / (PE/NP) (1^4] 

(J) (A) (software) A course of action to be taken to perform 
a given tosk. (B) (software) A written description of a course 
of action as m definition ^^A;-* for example, a documented test 
procedure, (CO (software) A portion of a computer program 
that IS named and thit performs a specific action. 

r4W^#* . (Q 610.12-1990 

(4) (software user docuihcntation) Ordered series of in- 
structions that a user follows to do one or more tasks. 

. . (CySE) 1065-1987r 

(5) (scheme programmmg language) A parameterized pro^ 
gram fragment, called a subroutine or fimction in some pro- 
gramming languages, (CTMM). 1178-l990f 

procedurc-orierited language (1) (computers) A program- 
ming language designed for the convenient expression of pro- 
cedures used in die solution of a wide class of problems. 

r^w ^ , e (MHVC) (21. (2bL {85J 

(Z>(soflware) ^ctf ai>o; procedural language. 

(Q 610.12-1990 

process (1) (automatic control) The collective functions per- 
formed m and by the equipment in which a variable is to be 
controlled. Synonym: controlled system. (PE/EDPG) PJ 

(2) (A) (software) A sequence of steps perform^ for a given 
purpose; for example, the software development process 
(B) (software) An executable unit managed by an operating 
system schediHer, See also: job; task. (Q (software) To per- 
form operations on data. (Q 610.12-1990 

(3) An address space and one or more direads of control that 
execute within diat address space, and dieir required system 

^ • «7PA) 14252-1996 

W A sequence of tasks, actions, or activities, including the 
transition criteria for prpgrcssing frbm one to the next, that 
^^^yr^ixlL (CySE) 1220-1994S 

(5) An address space and Uie single ducad of control diat 
executes within tfiat address space, and its required system 
resources. A process is created by another process issuing die 
POSIX.1 forkO ftmction. The process tfiat issues forkQ is 
known as the parent process, and die new process created by 
the forkO is known as tfic chUd process. The attributes of 
processes required by P0SIX.2 form a Subset of tfiose in PO- 

fr^^- (CyPA) 9945-2-1993 

(^)An address space with one or more tfueads executing 
witfiin tfiat address space, and die required system resources 
for tfiose tfucads. A process is created by anotfici^ process 
issumg tbtforiQ function. The process tfiat i^ues foHkQ is 
loHjwa as tfie parem process, and die new process created by 
thcforkO is knowa.as tfic child process. Many of tfje^tystcm 
resources defined by tfiis part of KO/IBG 9945 arc shared 
among aU of tfie tfueads witfiin a process. These include tfie 
process ID; tfie parent process ID; tfie process group ID; tfie 
session membership- tfie real, effective and saved-set user ID; 
the real, effective and savcd^ group ID; tfic supplementary? 
.^oop IDs; the current working directory; tfic root directorv 
tfie file mode creation mask; and file descriptors. 

nxA (CyPA) 9945-M996 

(7) An address space, and tfie program Oncluding any Ada 

tesks contained witfiin tfie program) executing witfiin tfiat ad- 
dicss space, and its required system resources.. A process is 
created by anotfksr process witfi procedures JPOSlxj»rbcess 
- Primitives. Start-Pix>cess, POSIJC-Probess. 
Primitives. Starti-Process-Search, or tfie function 
^slX-aosafe-Process-Primitives.Fork. The process 
•tfiat issues Start-Process. Start_Prpcess-Searc|i, or 
Fork IS known as tfie parent process, and tfie newly created 
goo«;sistfieciiiWproc^ (QPA) 1003:5-I992r 

W An addnss ^>acc. a sir^e tfiread of control to 

tfiAt address space, and its rexjuired system resources. 
On a systiOT tfiat implernente tfireads^ 
to cofisist of an address space, witfi one or more tfueads cx- 
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ccaiSag within that address space and tfaietr -required system 
lesomccs. NotesThc term process is used in contrast to **sys- 
tcm ptobcss." or the OSI usage of the term ^application 



(CyPA) 1327.2-1993W. 1224.2-I993w. 1326.2-I993w. 

~ I328;2-1993w 
. .■^) An orgaiUzcd set of activities pcrfdniied for a given pur- 
. " ' Dosc; for example, the software development process. 

*^ iOSm J-STCM)16-I995 

(10) A unit of activity chaiacteriBed by « jdngle, sequential 
' daead of execution, a cuircnt state, and on associated set of 
i^ctem resources, {C/MM^ 855-1990 

• (11) Sequence of opcratioa? perfonned in. and by the cquip- 
•fbent in which a vanablc is to be controlled. 

{SCC2Jd) 1226-1998 
' (U) (A) A set of iptcnelatcd actiWttes, which transforms 
inputs into outputs. Note: The term "actiyitics- covers use of 
*' • resoQTCcs. (B) A series of actions bringing about a result 

(QSE3 1490-1998 

■] {13)Consist5of aU execution within a -single distiiict address 
' space supported by the operating system of a computer, 
-ii; . XM/ST) 1451.1-1999 

/: tl4) ^^'oi^i'. POSIXptoocss. (C) 10033-1999 

^%^oo«^ A function that must be perfonned iri the software life 

cycle A Process is composed of Activities., 
j:; (C/SE) 1074-1995S 

process architect The person or group that has primary responr 
sibUity for creating and maiataihing- the. Software life cycle 
process (SLCP). See cdso: software life cycle process. 

(C/SE) 1074-1997 

.'iiFOcessable scored card A scored card.iiicluding at least one 
separable part that can be processed after separation. See also: 
_ stub card. (C) 6iQ.lO-l994w 

Process and Experiment Automation Realtime Language 
(PEARL) A gen^eral^-purpose, hig;h-order language designed 
to meet the tequarcments of real-dme fHOgrainming in process' 
and experiment automation. (Q 610.13-I993w - 

Process Architect The person or group that manages the im- 
plementation of the Standard in an organizatiorL 

(C/SE) 1074.1-1995 

process bound See: compute-bound. 

jilooess control (1) (electric pipe heating systems) The use of 

- electric pipe hcadng systems to increase or-maintain, or both, 
tfie teinpcfature of fluids (or processes) in mecfaariicai piping 

- systems including pipes, pumps, tanid, instrumentation in rui.- 

* dear power generating stations. (PE^PG) 622A-I984r 

(2) (automatic control) Control irnposed upon physical or 
' 'Cbemical changes tn a matfcriaL See also: feedback control 
^ cyacm. (PE/EDPQ [3] 

(3) (electric heat tracing systems) The use of electric heat 
' tracing systems to increase or maintain, c/f both, the temper-^ 

•■atape of fluids (or processes) in mechanical piping systems 

• * mrlra^ng pipcs, pumps, valves, tanks* instrumentation, etc. 
= -in power ^eneradng stations. (PE/EDPQ) 622B-1988r 

4 (4) AutDcnatic control in 'which a computer is used to regulate 
Gontinuous c^etations such as chemical processes, military 
... operations, or maruifacturing operations. See also: numcncal 

• lOQotroL (0)610.2-1987 
process equipmerif (automattc ixmtroO Apparatus with which . 
'^'^pfaysicai or cheinicai cfaaiiiges iri a material are produced. Syn- 

- ORjwi: plant- (PB/EDFG} f3] 
^V'BQe^ epq^lp (1) A collection <6f processes (hat permits the 

^t£;p^lS)^ i^ri^^ processes. Eadi process in- the system is 
y- a tnettihei' c^f it process grtMip that b ideatified by a process , 
^* ^ttMtp Id. a newly aeatcdt4irooes& joins tiic process grot^ oif 

its creator. (C/PA> 9945-l-1996» 9945-2-1993 

• * CZ)A CTUection of ptpccsses that permits die . signaling of 
.- reiatedptocesses. -EacfaproQess in the system. is amciriberof 

. a process group that ts identified by its prodess i^oop ID. A • 
V newly creiitcd process joins the proccss group of its creator. 

(O 1003-5-1999 



proc^ group ID (I) The uoique iddntificr representing a pro- 
cess group during its li^icne. A process ^oiip Il> is a positive 
intcgin' fiiat cari be contained. in a pull/. It shaH not be reused 
by. the systein until the process group* Ufetime eruis. 

(CTPA) 9945-1-19^. 9945-2-1993 
(2) A unique value identifying a process grprii^ffurirkg.its Ufe- 
tirne: A process group ID shall not be. roused by the system 
uritil die process j^tHip lifetime ends. (Qi 10033-1999 

process g^oup feader (1) A process whose process ID is the 
saoie as its process group ID. 

(C/PA) 9945rl-I99(5i 9945-2-1993 
(2) The uni<tae process, within a process group, that created 
the process group. (Q 10(B^-1999 

process sroup lifetime (1> A peripd of time thai begins when 
a process group is created and ends when the last remai n ing 
process in the group Ica^vcs die group, due eitfaer to the end 
of the last process's process lifctmic or to jthe last remaining 
process calling the setsidQ or setpgidQ functrons. 

(C/PA) 9945-1-1996 
(2) A period of time that begins when a process group is cre- 
ated and ends when the last remaining process in the group 
leaves the group, due either to the ieind of ^ process Uferime 
of the last process or to the last rcmaimng process calling the 
Seta»rocessjGroup.Io procedure;. (Q 1003.5-1999. 

process ID (1) The unique identifier representing a process- A 
process ID i^ a positive integer that cdn:be contained in a' 
ptti-r. A process ID shall not be reused by the system until 
the process lifetime ends. In additioti^ if tficre exists a process 
g^oup whose process group ID is equal to that process ID, 
the process ID shall not be reused by the system until the 
process group lifetime ends. A proixss that is rK>t a system 
process shall not have a process ID of 1. 

(C/PA) 9945-1-1996, 9945-2-1993 
(2) A unique value identifying a process during its lifetime. 
The process ID is a value of the type Process.lo defined in 
the package POSlJL--Process-id«:itiecatioii. A process 
ID shall not be reused by the system imtil the process lifetxmc 
.ends. In addidotu if a process group exists where the process 
ID of the process group leader is 'eqnal to that process ID. 
that process ID shall riot be reused by the systerrl until the 
process group Ufetinieends. An irnplemcntation shall reserve 
a value of process ID for use by system processes. A process 
that is not a system process sh^U not have this process ID. 

(Q 1003.5-1999 

processing See.- itiultiprocessing: parallel processing; data pro- 
cessing; information processing, 
proicessing cyde A single, complete execution of data proccss- 
- ihg that is periodically repeated. Synonym: dlata processing 
cycle. See also: daily cycle; monthly cycle; weekly- cyde; 
annual cycle. (C) 610.2-1987 

processing uittt A functional unit that consists of one or more 
processors and their storage. See also:.caiXxsii processing unit 

(Q 610.10-1994W 

process lifetime (1) The period of time that begins when a pto- 
' cess is created and cods when its process ID is returned to 
the system. Afier.a process is created with ^forioQ function^ 
it is considered acrivc. At least one thread of control arid the 
address ^liace enst until it terminates: It then enters an'in-. 
. active ^tale .wfaae oertairl resources may be returned to (he 
system, altfaougli some resources, such as the process ID.^arc 
stin in' use. When arKXhcr fnocess executes a MAoirO <t 
pu^ function for an inactive process, the re maining resources 
are retiirned to the system. The last resource to be retuAoed. 
to, the systein is -the process' ID. At this time, die lifetime of 
die process ends, (CyPA) 9945-M996 

(2) A period of tirnc that begins when a process is -cri^ited 
abd tads-wfaenits process ID is returned to the system. After 
a process ts created, it is 'considered active. Its threads of 
control and address q>aoe exist until it tetminaies.' it^ diea- 
' enters an inactive -state where certain resources may be re- 
turned to die system^ although sonie rcsooices, such as the 
process ID,, arc still in use. When aivxherprotess cxecotcsa 
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cuncnt dcfuftcy tn ttie duci^tioin of the tentperahue giadichf t$ 
posibvo. See a£s^- thcrmoclbctnc devtec (Hp) [46) 

^ Thccpsoiv cfTfcct The absorpdoo pr cvolutjon of thennat esiem 
'|koduct4^y tfie ime^^ 
pcra&ne ^^ccfit in a homogcocd^ 
- -K An ctectromotivc force exists between two pomts'In a 
- siogtc conductor diat are at itifiercnt tcm^cfaturcs; tWoisig- 

Hitudc and difcctioa of dfce^ectrodioiive fence cfepcod 6ci 
. maficfiaJof diecondoctor. Aoonseq[ueDceof dus f^ect 
if a corrcfU exists in a conductor 

fcrau tomperatmes, Iida2 wfl* be absocbedor ta>eiatc<l <fo- 
pendins on tfjc malarial and on fttb sense of the cuncnt. Z In 
> nonhomogeneotts conductor, did Pdtier cfTfect and the 
Thomson effect caiuK>t be sepaiatedL ^tftf als;a 
Advice. ^>t46J 
Thomsoo heat The dimna^ en(»gy af>sofbc^ or evotvo^ a 
. result of die Thomson eifect 5etf flZjo- ttenioclccf^ 

(ED) [46) 

(lirasfaing A state in which a computer sys-tetii is expending 
most or all of its resources on ovetfacad operations, such as^ 
swapping data between main and auxiliary storage, rather 
tfian on intended computing fufiction$. (Q 610.12-1990 

thread (1) (control) A control function that ptovidcs Cor inain- 
tained operation of a drive at a preset reduced speed such as 
for setup.putposcs. a£pa; electric driv<i.' 

• . . ^ (lA/rcruuG) [60) 

i2) (data: management) In a tree, a set of link fields, one in 
each node, each of which points to d>c successor or predc^ 
ccssorofdiat nodc with lespcct.to a particular traversal o^^ 

CC>6tOJ5:-1990w 
(3) A stogie sequential flow of control within a process^ ' 
(CyPA) I328.2.1993W, 1326^-1993w. 1224.2nt993w. 

1327a-1993w, 14253t-1996 
-("O A sii^ flow of <ontr(^:Widitn a process. Eac^ thread has 
^ own duead ID. schedulihg priori^ and policy, ^mw value, 
tfuca*spc;afic key/value bindings, and the required sy^baa 
T^ources to support a flow of fcontroL Ahydiing whose ad- 
dress may be dctcrrnined by a thread, including but not lim- 
ited to static yariabres, storage obtained via /naii<>cO: directly 
. -addressable storage obtained dnpugji impfcmentaiion-sup- 
plied functions, and automatic variables shall be accessible 
to :aU thrcsuls in- the sankc process.- : {QRA)' 99t45- 1- 1996 
^reade^ coupling (rigid s(ed conduit) An ihtemaUy direaded 
steel cylinder for connecting two sections of rigid steel con- 
: ^ (EEQCX>N) (28J 

Ihre^ded tr^Atrcewfadsenod^ for one or 

ttocal^ aUowing nonrocursive traversal of the tree See 
ator>ft^hieaded tree; triply-threaded tree; doitbly-lhrteaded 
tiec: ri^-tbicaded trccL (€) 6lp^l990w 

thread ID A unique v^uc oitype^ pth-ead^ that identifies each 
thread dudng its lifethnc m ^ pioccss. 

(CyPA) 9945-1-1996 
.threading fide (conductor stringuog eqitipin<^() A li^eigftt 
flexible line, norma^y mantU or^nithetic fiber rope, used to - 
- lead a pondoctor 0upi)^ tbe bullwfabels of a teti^ioQcr or 
:pullh?gfiDe Ifarbiigh^abull/^^p^ Syiumyms: threading 
i^ bua Unc. ^ . (tAi>/PE) 524-I992r 

'thwa^iilg ropc-Sfti.- tfateadtiig Kdcl . ' . 
ihread list An ordered set ^t>f runfuOOe threads th^ all have die 

'on Oe fist is ilctefnHaed by a schcdvOing policy or poi^rics. 

^[W? spit of ^ircM^lisis tnciodds'aU rcumable ^tvcads m tfwi 

((7PA) 9945^l-f9?<5 
*f^^^<»nWl A ^ys qt ritifr b^^ instructions dxec^ed i^'a 

te^x^ basi'^^jjaaa^sl^ inde{KXKiicia of itiy pro- 

'^^grammi^ buigt^e^ IK&c diah one tfarfcad of .(x»ttn>l may 
V^^^c coiwaaiiwidy. iiiie^dd too a jni^ic processor. br;ofi 
V septate pstK2e?sois.:|^c^^ i^^. 

Aaa ap(^ica(t6n>re Ada Cdsfcs. thj^.m^y, but^icic^ riot, cor- 

le^potid to Ih^K^K^ditca^ 
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, thread^safe A functionthat tiiay be safdly invoked cbficurrent^. 
by nmltiplc threack Each fun^ 

ttec^-safe unless cxplccitiy stated odEicrwisp. Aji ex^Unptb 
any ''pure*' fiinctidn (a^ fiuidiofi th^ Ublds a my^cx ^l^ci^ 
while it is accessing static storage or. Objects shaM am^h^ 
^'*?'^)- (QfPAJ 9^5^1-1996' 

thread-spectfic daU key' A process global handle^ oT 
' pthreadJcey^ diat is M$cd .for naming llk^a^^siMi^fie: 4a^. 
Aldiough the same key valiid ou^.bc u^ed % ^^B^smxt 
threads^ the values botmd to the key hf^p^eatL^ii^f^^cQ. 
irtd accessed by pthread^etspe^ificQ m tdaintaiiicd ga a 
pcr-tfaread basb and persist for tlje Gfi; of tfk; calEng dnead: 

(€yPA) 9945-l-l99f 
threat (1) Apotcnttat viobtioo of secoi^, 

(U4/P) 8aLl(fe-|?95^SaLi(KI992 
(2) Means by which a system m^y be adversely affected: 
Threats include btxh ina^vcrteot and maliciouf actions. 

(OBA) 8963-1993^ 
three-address P^^rtaining to an instmctido code in whi<^ exH ' 
instructioo has three address pirk iMso called tripT^^ 
In apical three-address instruction the addressee spcc^ the 
location df two operands and die destination of the r6s^ 
. the instructions aietalxn from storage in a prea^^ 

two-plus-one address. (€> t6Z-i^yr . 

thrc^address instruction (1) A computer instnictibn that om- 
tains three address fields. For oxam^l^ an instriktion-to add 
the contents of locations A and Bi. aiki.piace the results in 
location C Contrast: four-addccss instniGtibn; pne-addrcss. 
instractiGh; zero-address instruct!^ t^^^adc&ess instruc^iocL 
^ . (CDr'6iai?i-t990 
W An instruction containing dit^'addressesL ^aonjm: ti^- 
ple-addrcss instruction. See also: address format. 

(O 6M).ia-1994w 

three-bit- byte triplet, 
three-conductor bundle See: bundle, 

three-dimerisionargraphics The presentation of data on.a tw<^ 
dimensional disphy sur^^ so that it a^pc^ to represent i 
threp-dimensional mc^del, and can be viiewcd from any posi- 
tion, y/pr^.- Each coordinate of rfte ihodd contkins a triplet of 
inforrnatioo; for example, x; y, and x in ^ Cufesian coor- 
dinate system, (Q 6ia.i5-U^lw 
thrce-dimerisional hardware A mphical dispkiy processor 
that acc«^ tfuec^dimensionai iiUoiina^^ 
crates an image direcdy rather than usiqg a projection ttans- 
fotmation. (Q 610.^199iw 
three-dimeosional priority the {nopeity possessed by a Hoe 
or surfece diat is in front of another line or sur&oe ftoAi die 
viewer's perspectives (C? 610j6^991w 
three-dunenaonai radar (nari^tion aid Urmsy A ladar ca- 
pable of produong dueendimmsiori^ 
tiplicity of targets. (AES/GCS) 686^1997, m-1983w 
- 3GL See: high-order language. ' 
three-input adder ^e^j fidl'addcr. 
thi^e-leVa. address n4evei addc^ 

3^f-9 bar code A variable lehgdi, Hdireci^^nal; difi^x^ self-r * 
checldng,aIphaHiuinerictnrood8;,^i^ 
contaSns 43 characters: 6 lo 9. A to 2; K ^ /. -|-. %^ aiid 
^paoil .Each aiaractcr b c^^ 

4 spaces. Thtee'of the nine etetnents are wide (binaiy value 
- . i> and six ate narrow (btnauy va}ue 0). Acotmiion <&racter 
<^ is used cKctosiVety fOT botf^a 

0^!E/i^ CS7A23S-1996 

thince-phase M4s<aecMic '^^^ 

p6wer.lin€s):T&©b-rt2K^ ■ 
i^iasi^ field t«d»s& 

^eM at aby pc^ ^be de$c^icd tr^ tbfe fi^ 
ky tlK magnitodc and ^fircciioa ^Ific scmi-^ia^.atk arid 
dtt ruagnitudc aikl dirccfibn of its sernt^^ 
P&asc field, the aect&.fic^ at tar^dtst - 
frqm dic'ouficrphascs^(^^ ' 
<^ a single^pfaase field bci^ 
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'^f^^Od (thr6d) n. 1 -jgi. Flue crqrii of a fibrous^ materiali,s|i^ 
CQtton or made of Xm^ or more Maments- tmstedtf^^er 
.us^ in needlework and l^e weavip^ ol pieeie of such 

c<^d. 2. a. A t\un strand, cord, pr^rfilamenf . oi Vri^^^ pr liEaaau- 
|a9tuj:ed material. Somejthing that su^^ fineness or 

thinnes^,of such ^ strai^i, cord, pr. filament: athreqd of smbke. c. 
Spmethixig that suggests tjie cpntinuousness of such a strand, 
..9ord,,pf; fUament: iost t^^^ thread ofhi$ argument J Z. A helical or 
spirialridge pn a screw- nut, or bolt. 4.,«l:ireads. Slangl 6\oihes. 
^thread y,, threqcl red> threqid* icig, threqds. ^ tr, 1. Td 
pass one end of a thread thrQHghvihe;,^ye of fpr exam- 

ple), b. Tp.,pj5S (something) through in the planner, of a, thread 
thread the yxire through, the ppentng,, c,. Tpsgass a: tape! br . jEihn 
into or through (a cJevice): ^i^adqJibnrpn^ecUjr^ , d. Tp pass^ (a 
tape or film} into or through a deivi^e. 2. To cdnnect jay m^^^ 
a. thread through; string: thrfiad bieads, 3,Q, To make, one's way 
cautiously through: threading dark:" dUeys.. b. To make -(one's 
way) cautiously through spmet^ng; 4. To. occur here ^d-ttiere 
throughput; pervade: ;f*Afpre *hon 90:5^o?oflrte thr.ead.the Los 
Angeles arear (Science; News), 5.. To vmaGhine.a .thread on <a 
screw, niit, of; bjplt). ^intir, f; ,Tp < make -one's way cautiously: 
threaded through: the-sh^ials, and^si^dtmrsir^ !^^ by a 

: winding course. 3. "I^o fojm a threap whfen^dri^^^ spoon, 

; as boiling sugar syrup, [Middle^EngUshi JQld English t/irSa. 

:,.See ^ro-»;;in ^Ependix'^rH.fjH^^ 

threads* b^re (thrCd? bar') aaj. ' Jiv Having- the nap worn down 
so that the filling or warp'threadsr^how^^through; frayed' or sh&b- 
hy: threadbare Tiigs.. 2. Wearing old> shabliy.:clothingi 3^ Oyer- 
. used t©^ the, . point :of being wont out? hackriey«i: threadbareS ex- 
cuses. See Synonyms at trife. 7;, ■-, ^ . , , 
threadTfiti (thrgd^fin') n., pi. threadfin or'^fms. Any of var- 
; .rousahiefly tropical marineiishespf the fknuiy PSlyneriiMae, hav^ 
tngfthreadlifce. raysi extending iirom the lawec {)art ofith© pfectPral 

thread * worm (thrgd' vmrm>^? n. 'See^ihworm^ : 5 f V 
thread-y (thr&l/'e) • 4.eri*^^^ 

sembling thread; fUamehtb&s^ ;2^^Cai)able ctf ffe^g Bi? 

to 'form threadsT viscidr: Zv~.Medicine. Weak* and shlflSwi il^Sfediit 
• ;A?pul^e. 4. Lackmg,jfuUriess of tQn§^':thinc^l^4^/lr^aay ;«^ice. 

. — thread' i'ness-n. • ; a.. ■v=!i"??-2'-i.^4>f*i. .... i..-. :.;=r^;i:-;.-A. 
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Thread (computer science) 

From Wikipedia, the free encyclopedia. 

A thread in computer science is short for a thread of execution or a sequence of instructions. Multiple threads can be executed in 
parallel on many computer systems. This multithreading generally occurs by time slicing (where a single processor switches 
between different threads) or by multiprocessing (where threads are executed on separate processors). Threads are similar to 
processes, but differ in the way that they share resources. 

Many modem operating systems directly support both time-sliced and multiprocessor threading with a process scheduler. The 
operating system kernel allows progranmiers to manipulate threads via the system call interface. Some implementations are 
called kernel threads or lightweight processes. 

Absent that, programs can still implement threading by using timers, signals, or other methods to interrupt their own execution 
and hence perform a sort of ad-hoc time-slicing. These are sometimes called user-space threads. 

Threads are a way for a program to split itself into two or more simultaneously running tasks. (The name "thread" is by analogy 
with the way that a number of threads are interwoven to make a piece of fabric). 

A common use of threads is having one thread paying attention to the graphical user interface, while others do a long calculation 
in the background. As a result, the application more readily responds to user's interaction. 

An unrelated use of the term thread is for threaded code, which is a form of code consisting entirely of subroutine calls, written 
without the subroutine call instruction, and processed by an interpreter or the CPU. Two threaded code languages are Forth and 
early B progranruning languages. 
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Threads compared with processes 

Hireads are distinguished from traditional multi-tasking operating system processes in that processes are typically independent, 
caiiry considerable state information, have separate address spaces, and interact only through system-provided inter-process 
communication mechanisms. Multiple threads, on the other hand, typically share the state information of a single process, and 
share memory and other resources direcdy. Context switching between threads in the same process is typically faster than context 
switching between processes. Systems like Windows NT and OS/2 are said to have "cheap" threads and "expensive" processes, 
■■ while in other operating systems there is not so big a difference. 

An advantage of a multi-threaded program is that it can operate faster on computer systems that have multiple CPUs, CPUs with 
multiple cores, or across a cluster of machines. This is because the threads of the program naturally lend themselves for truly 
concurrent execution. In such a case, the progranmier needs to be careful to avoid race conditions, and other non-intuitive 
behaviors. In order for data to be correctiy manipulated, threads will often need to rendezvous in time in order to process the data 
in the correct order. Threads may also require atomic operations (often implemented using semaphores) in order to prevent 
conmion data from being simultaneously modified, or read while in the process of being modified. Careless use of such 
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primitives can lead to deadlocks. 

Operating systems generally implement threads in one of two ways: preemptive multithreading, or cooperative multithreading. 
Preemptive multithreading is generally considered the superior implementation, as it allows the operating system to determine 
when a context switch should occur. Cooperative multithreading, on the other hand, relies on the threads themselves to relinquish 
control once they are at a stopping point. This can create problems if a thread is waiting for a resource to become available. The 
disadvantage to preemptive multithreading is that the system may make a context switch at an inappropriate time, causing 
priority inversion or other bad effects which may be avoided by cooperative multithreading. 

Traditional mainstream computing hardware did not have much support for multithreading as switching between threads was 
generally already quicker than full process context switches. Processors in embedded systems, which have higher requirements 
for real-time behaviors, might support multithreading by decreasing the thread switch time, perhaps by allocating a dedicated 
register file for each thread instead of saving/restoring a conmion register file. In the late 1990s, the idea of executing instructions 
from multiple threads simultaneously has become known as simultaneous multithreading. This feature was introduced in Intel's 
Pentium 4 processor, with the name Hyper-threading. 

Processes, threads, and fibers 

The concept of a process, thready and fiber are interrelated by a sense of "ownership" and of containment, 

A process is the "heaviest" unit of kernel scheduling. Processes own resources allocated by the operating system. Resources 
include memory, file handles, sockets, device handles, and windows. Processes do not share address spaces or file resources 
except through explicit methods such as inheriting file handles or shared memory segments, or mapping the same file in a shared 
way. Processes are typically pre-emptively mukitasked. However, Windows 3.1 and older versions of Mac OS used co-operative 
or non-preemptive multitasking. 

A thread is the "lightest" unit of kernel scheduling. At least one thread exists within each process. If multiple threads can exist 
within a process, then they share the same memory and file resources. Threads are pre-emptively multitasked if the operating 
system's process scheduler is pre-emptive. Threads do not own resources except for a stack and a copy of the registers including 
the program counter. 

In some situations, there is a distinction between "kernel threads" and "user threads" ~ the former are managed and scheduled by 
the kernel, whereas the latter are managed and scheduled in userspace. In this article, the term "thread" is used to refer to kernel 
threads, whereas "fiber" is used to refer to user threads. Fibers are co-operatively scheduled: a running fiber must explicitiy 
"yield" to allow another fiber to run. A fiber can be scheduled to run in any thread in the same process. 

Thread and fiber issues 

Typically fibers are implemented entirely in userspace. As a result, context switching between fibers in a process is extremely 
efficient: because the kernel is oblivious to the existence of fibers, a context switch does not require any interaction with the 
kernel at all. Instead, a context switch can be performed by locally saving the CPU registers used by the currentiy executing fiber 
and loading the registers required by the fiber to be executed. Since scheduling occurs in userspace, the scheduling policy can be 
more easily tailored to the requirements of the program's workload. 

However, the use of blocking system calls in fibers can be problematic. If a fiber performs a system call that blocks , the other 
fibers in the process are unable to run until the system call returns. A typical example of this problem is when performing I/O: 
most programs are written to perform I/O synchronously. When an I/O operation is initiated, a system call is made, and does not 
return until the I/O operation has been completed. In the intervening period, the entire process is "blocked" by the kernel, and 
cannot nm - which starves other fibers in the same process from executing. 

A common solution to this problem is providing an I/O API that implements ia synchronous interface by using non-blocking I/O 
internally, and scheduling another fiber while the I/O operation is in progress. Similar solutions can be provided for other 
blocking system calls. Alternatively, the program can be written to avoid the use of synchronous I/O or other blocking system 
calls. 

Win32 supplies a fiber API. SunOS 4.x implemented "light-weight processes" or LWPs as fibers known as "green threads". 
SunOS 5.x and later, NetBSD 2.x, and DragonFly BSD implement LWPs as threads as well. 
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The use of kernel threads brings simplicity; the program doesn't need to know how to manage threads, as the kernel handles all 
aspects of thread management. There are no blocking issues since if a thread blocks, the kernel can reschedule another thread 
from within the process or from another, nor are extra system calls needed. 

However, there are obvious issues with managing threads through the kernel, since on creation and removal, a context switch 
between kernel and usermode needs to occur, so programs that rely on using a lot of threads for short periods may suffer 
performance hits. 

Hybrid schemes are available which provide a tradeoff between the two. 
Relationships between processes, threads, and flbers 

The operating system creates a process for the purpose of running a program. Every process has at least one thread. On some 
operating systems, processes can have more than one thread. A thread can use fibers to implement cooperative multitasking to 
divide the thread's CPU time for multiple tasks. Generally, this is not done because threads are cheap, easy, and well 
implemented in modem operating systems. 

Processes are used to run an instance of a program. Some programs like word processors are designed to have only one instance 
of themselves running at the same time. Sometimes, such programs just open up more windows to acconmiodate multiple 
simultaneous use. After all, you can go back and forth between five documents, but you can edit one of them at a given instance. 

Other programs like command shells maintain a state that you want to keep separate. Each time you open a conmiand shell in 
Windows, the operating system creates a process for that shell window. The shell windows do not affect each other. Some 
operating systems support multiple users being logged in simultaneously. It is typical for dozens or even hundreds of people to be 
logged into some Unix systems. Other than the sluggishness of the computer, the individual users are (usually) blissfully unaware 
of each other. If Bob runs a program, the operating system creates a process for it. If Alice then runs the same program, the 
operating system creates another process to run Alice's instance of that program. So if Bob's instance of the program crashes, 
Alice's instance does not. In this way, processes protect users from failures being experienced by other users. 

However, there are times when a single process needs to do multiple things concurrently. The quintessential example is a 
program with a graphical user interface (GUI). The prograni must repaint its GUI and respond to user interaction even if it is 
currently spell-checking a document or playing a song. For situations like these, threads are used. 

Threads allow a program to do multiple things concurrendy. Since the threads, spawned by a program, share the same address 
space, one thread can modify data that is used by another thread. This is both a good and a bad thing. It is good because it 
facilitates easy conmiunication between threads. It can be bad t>ecause a poorly written program may cause one thread to 
inadvertently overwrite data being used by another thread. The sharing of a single address space between multiple threads is one 
of the reasons that multithreaded progranmiing is usually considered to be more difficult and error-prone than programming a 
single-threaded application. 

There are other potential problems as well such as deadlocks, livelocks, and race conditions. However, all of these problems are 
concurrency issues and as such affect multi-process and multi-tiber models as well. 

Threads are also used by web servers. When a user visits a web site, a web server will use a thread to serve the page to that user. 
If another user visits the site while the previous user is still being served, the web server can serve the second visitor by using a 
different thread. Thus, the second user does not have to wait for the first visitor to be served. This is very important because not 
all users have the same speed Internet connection. A slow user should not delay all other visitors from downloading a web page. 
For better performance, threads used by web servers and other Internet services are typically pooled and reused to eliminate even 
the small overhead associated with creating a thread. 

Fibo^ were popular before threads were implemented by the kernels of operating systems. Historically, fibers can be thought of 
as a trial run at implementing the functionality of threads.. There is litde point in using fibers today because threads can do 
everything that fibers can do and threads are implemented well in modem operating systems. 

Many software developers believe that in most cases attempts to use fibers actually decrease the performance of an application. 
There are several reasons for this. First, the use of fibers does not increase the percentage of CPU time that the operating sytem 
gives to a process. Second, in typical multithreaded or multifibered code there is contention for shared resources like variables. 
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Progfamming constructs like semaphores and critical sections are used to solve problems that multithreading and multifibering 
create. Often these tools are implemented more efficiently in the operating system than in user libraries, particularly if those 
libraries are not written in assembly language. Third, as users install newer vereions of an operating system, improvements may 
be made to the kernel scheduler, operating system provided semaphores, etc. User libraries do not see these benefits unless they 
call libraries provided by the operating system. 

A case where fibers still can be helpful is when the limits of the OS in terms of number of threads per process are reached (for 
example 2000-3000 threads). In this case context-switching, which includes a system call, is too expensive and fibers can help. 
Tliis situation may happen, for example, in a server that spawns a new thread for each incoming request. 

Implementations 

There are many different and incompatible implementations of threading. These can either be kernel-level or user-level 
implementations. 

Note that fibers can be implemented without operating system support, although some operating systems or libraries provide 
explicit support for them. For example, recent versions of Microsoft Windows (Windows NT 3.51 SP3 and later) support a fiber 
API for applications that want to gain performance improvements by managing scheduling themselves, instead of relying on the 
kernel scheduler (which may not be tuned for the application). Microsoft SQL Server 2000*s user mode scheduler, running in 
fiber mode, is an example of doing this. 

Kernel-level implementation examples 

■ LWKT in various BSDs 

■ M:N threading (in BSDs) 

■ NPTL Native Posix Threading Library for Linux from Red Hat 
User-level implementation examples 

■ FSUPthreads 

■ LWP 

Comparison between models 

An operating system can provide support for processes, threads, and fibres in any combination; which of these it provides will 
have a significant impact on its overall behavior and characteristics. 



In the table below, P stands for processes, T stands for threads, and F stands for fibers. 



p 


T 


F 


Example 


X No 


X No 


XNo 


A program running on DOS. The program can only do one thing at a time. 


X No 


Jf No 


y Yes 


Windows 3.1 running on top of DOS. All Windows programs are run within a single process, so the 
programs can corrupt each other's memory space. A poorly written program could corrupt data it didn't 
own, causing the infamous General Protection Fault 


X No 


y Yes 


X No 


Amiga OS's original implementation. The operating system had full thread support, allowing multiple 
applications to run independendy of each other which are scheduled by the kernel. The lack of process : 
support resulted in a more efficient system (by avoiding the overhead of memory protection), with die 
price that application bugs could easily crash the entire computer. 


X No 


/Yes 


/Yes 


This case is used oniy in embedded systems and small real-time operating systems. Theoretically 
possible in a general purpose operating system, but no known examples. 


✓ Yes 


X No 


XNo 


Most early implementations of Unix. The operating system could run more tiian one program at a time, 
and programs were protected from each other. If a program behaved badly, it could crash its process 
ending that instance of the program without disrupting the operating system or other programs. 
However, due to this protection, sharing information between programs was error-pnjne (using 
techniques like shared memory) and expensive (using techniques like message passing). Performing any 



http://en.wikipedia.org/wiki/Thread_%28computer_science%29 September 14, 2005 









tasks asynchronously required an expensive forkO system call. 


/Yes 


X No 


✓ Yes 


Sun OS before Solaris. Sun OS is Sun Microsystem's version of Unix. Sun OS implemented "green 
threads" in order to allow a single process to asynchronously perform multiple tasks such as playing a 
sound, repainting a window, and responding to user events such as clicking the stop button. Although 
processes were pre-emptively scheduled, the "green threads" or fibers were co-operatively multitasked. 
Often this model was used before real threads were implemented. This model is still used in 
microcontrollers and embedded devices. 


✓ Yes 


✓ Yes 


XNo 


This is the most conmion case for applications running on Windows NT. Windows 2000, Windows XP, 
Mac OS X, Linux, and other modem operating systems. Although each of these operating systems 
allows the progranuner to implement fibers or use a fiber library, most programmers do not use fibers in 
their applications. The programs are multithreaded and run inside a multitasking operating system, but 
perform no user-level context switching. 

On the typical home computer, most running processes have two or more threads. A few processes will 
have a single thread. Usually these processes are services running without user interaction. Typically 
there are no processes using fibers. 


✓ Yes 


✓ Yes 


✓ Yes 


Almost all operating systems after 1995 fall into this category. The use of threads to perform concurrent 
operations is the most common choice, although there are also multi-process and multi-fiber 
applications. Threads are used, for example, to enable a program to render its graphical user interface 
while waiting for input from the user or performing a task like spell checking. 



Example of multithreaded code 

This is an example of a simple multi-threaded program written in C#. The program illustrates the use of threads and a possible 
outcome of executing it on the Linux platform. Note, the outcome is not fixed and these threads could potentially lead to a "race 
situation." 



using System; 
using System. Threading ; 
, public class ThreadWork C 

public static void DoWorkO { 
for (int i = 0; i<3;i++) { 

Console.WriteLine( "Worker thread ...*); 
Thread. Sleep (100 ) ; 

} 

} 

) 

class ThreadTest( 

public static void Main() { 

ThreadStart myThreadDe legate = new Thr eadS tart {ThreadWork. DoWork) ; 

Thread rayThread = new Thread(myThreadDelegate) ; 

myThread . Start { ) ; 

for (int i = 0; i<3; i++) { 

Console.WriteLineCin main.''); 
Thread.Sleep(100) ; 

) 

) 

> 



One possible set of output is: 



In main. 

; Worker- thread . . . 
: In main. 

. worker thread . . . 
: In main. 

■ Worker thread . . . 



See also 



List of multi-threading libraries 
cloneO 
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■ Communicating sequential processes 

■ completion port 

■ computer multitasking 

■ forkO 

■ Lock-free and wait-free algorithms 

■ message passing 

■ priority inversion 

■ synchronization 

■ thread safety 
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• Recall that a process includes many things 

♦ An address space (defining all the code and data pages) 

♦ OS resources (e.g., open files) and accounting information 

♦ Execution state (PC. SP, regs, etc.) 

• Creating a new process is costly because of all of the 
data structures that must be allocated and initialized 

♦ FreeBSQ 81 fields, 408 bytes 

...which does not even include page tables, etc. 

• Communicating between processes is costly because 
most communication goes through the OS 

♦ Overhead of system calls and copying data 
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Parallel Programs 

• Also recall our Web server example that forks off copies 
of itself to handle multiple simultaneous requests 

♦ Or any parallel program that executes on a multiprocessor 
. To execute these programs we need to 

♦ Create several processes that execute in parallel 

♦ Cause each to map to the same address space to share data 

» They are all part of the same computation 

♦ Have the OS schedule these processes In parallel (logically or 
physically) 

• This situation is very inefficient 

♦ Space: PCB, page tables, etc. 

♦ Time: create data structures, fork and copy addr space, etc. 
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Rethliiking Processes 

• What is similar in these cooperating processes? 

♦ They all share the same code and data (address space) 

♦ They all share the same privileges 

♦ They all share the same resources (files, sockets, etc.) 

• What don't they share? 

♦ Each has its own execution state: PC. SP, and registers 

• Key idea: Why don't we separate the concept of a 
process from its execution state? 

♦ Process: address space, privileges, resources, etc. 
> Execution state: PC. SP, registers 

. Exec state also called thread of control, or thread 
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Threads 



• Modern OSes (Mach, Chorus. NT. modern Unix) 
separate the concepts of processes and threads 

♦ The thread defines a sequential execution stream within a 
process (PC, SP. registers) 

♦ The process defines the address space and general process 
attributes (everything but threads of execution) 

• A thread is bound to a single process 

♦ Processes, however, can have mulliple threads 

• Threads become the unit of scheduling 

♦ Processes are now the containers in which threads execute 

♦ Processes become static, threads are the dynamic entities 
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Threads in a Process 
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Thread Design 






One Thread/Process 
One Address Space 
(MSDOS) 



Address Space 
Thread 




Many Threads/Process 
One Address Space 
(Pilot, Java) 



One Thread/Process 
Many Address Spaces 
(Unix) 




Many Threads/Process 
Many Address Spaces 
(Mach, OSF. NT. Chorus) 
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Process/Threaci Separation 

• Separating threads and processes makes it easier to 
support multithreaded applications 

♦ Creating concurrency does not require creating new processes 

• Concurrency (multithreading) can be very useful 

♦ Improving program structure 

♦ Handling concurrent events (e.g.. Web requests) 

♦ Writing parallel programs 

• So multithreading is even useful on a uniprocessor 
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Threads: Concurrent Servers 



. Using fork() to create new processes to handle 
requests in parallel is overkill for such a simple task 

• Recall our forking Web server: 

while (1) ( 

Int sock = accept ( ) ; 

If ((childjid a forkO) 0) { 

Handle client request 
} else { 
Close socket 

> 

> 
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Threads; Cencarrent Senrei^ 



• Instead, we can create a new thread for each request 

w^_seirver() { 
while (1) { 
int sock o acceptO; 
thread_f ork (hazidle__re<iues t ; sock ) ; 

> 

} 

.handle_request(iiit sock) { 
Process request 
close (sock); 

> 
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Kernel-Level Threads 



• We have taken the execution aspect of a process and 
separated it out into threads 

♦ To make concurrency cheaper 

. As such, the OS now manages threads and processes 

♦ All thread operations are implemented in the kernel 

♦ The OS schedules all of the threads in the system 

• OS-managed threads are called kernel-level threads 
or lightweight processes 

♦ NT: threads 

♦ Solaris: lightweight processes (LWP) 
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Kernel Thread Limitations 



• Kernel-level threads make concurrency much cheaper 
than processes 

♦ Much less state to allocate and initialize 

• However, for fine-grained concurrency, kernel-level 
threads still suffer from too much overhead 

♦ Thread operations still require system calls 

» Want thread operations to be as fast as a procedure call 

♦ Kernel-level threads have to be general to support the needs 
of all programmers, languages, runtimes, etc. 

• For such fine-grained concurrency, need even 
"cheaper" threads 
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User-Level Threads 



• To make threads cheap and fast, they need to be 
implemented at user level 

♦ Kernel-level threads are managed by the OS 

♦ User-level threads are managed entirely by the run-time 
system (user-level library) 

• User-level threads are small and fast 

♦ A thread is simply represented by a PC, registers, stack, and 
small thread control block (TCB) 

♦ Creating a new thread, switching between threads, and 
synchronizing threads are done via procedure call (no kernel 
involvement) 

♦ User-level thread operations 100x faster than kernel threads 
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U/L Thread Limitatioiis 



• But, user-level threads are not a perfect solution 

♦ As with everything else, they are a tradeoff 

• User-level threads are invisible to the OJS 

♦ They are not well integrated with the OS 

• As a result, the OS can make poor decisions 

♦ Scheduling a process with idle threads 

♦ Blocking a process whose thread initiated an I/O, even though 
the process has other threads that can execute 

♦ Unscheduling a process with a thread holding a lock 

• Solving this requires communication between the 
kernel and the user-level thread manager 
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Kernel vs. User Threads 



. Kernel-level threads 

♦ Integrated with OS (informed scheduling) 

♦ Slow to create, manipulate, synchronize 

• User-level threads 

♦ Fast to create, manipulate, synchronize 

♦ Not Integrated with OS (uninformed scheduling) 

• Understanding the differences between kernel and 
user-level threads is important 

♦ For programming (correctness, performance) 

♦ For test-taking 
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Kernel and User Threads 



• Another possibility is to use both kernel and user-level 
threads 

♦ Can associate a user-level thread with a kemeNevel thread 

♦ Or, multiplex user-level threads on top of kemeMevel threads 

• Java Virtual Machine (JVM) 

♦ Javia threads are user-level threads 

♦ On older Unix, only one "kernel thread" per process 

» Multiplex all Java threads on this one kernel thread 

♦ On NT. Solaris. OSF 

» Can multiplex Java threads on multiple kernel threads 
» Can have more Java threads than kernel threads 
» Why? 
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User and Kernel Threads 




Multiplexing user-level threads Multiplexing user-level threads 

on a single kernel thread for on multiple kernel threads for 

each process each process 
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Ifnuieineiiting Threads 

• Implementing threads has a number of issues 

♦ Interface 

♦ Context switch 

♦ Preemptive vs. non-preemptive 

♦ Scheduling 

♦ Synchronization (next lecture) 

• Focus on user-level threads 

♦ KemeNevel threads are similar to original process 
management and implementation in the OS 

♦ What you will be dealing with in Nachos 

♦ Not only will you be us/ng threads in Nachos. you will be 
implementing more thread functionality 
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Thread Interface 


• thread fork^Drocedurp 




♦ Create a new thread of control 




♦ Miso inreaa_creaie^}, inreao_seistaie() 




• thread_stop() 




♦ Stop the calling thread; also thread_block 




• thread_start(thread_t) 




♦ start the given thread 




• thread_yield() 




♦ Voluntarily give up the processor , 




. thread_exit() 




♦ Tenminate the calling thread; also thread_destroy 
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Thread Schedluling 

• The thread scheduler determines when a thread runs 

• It uses queues to keep track of what threads are doing 

♦ Just like the OS and processes 

♦ But it is implemented at user-level in a library 

•\ Run queue: Threads currently running (usually one) 

• Ready queue: Threads ready to run 

• Are there wait queues? 

♦ How would you implement thread_sleep(time)? 
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Non-Preemptive Scheduling 

• Threads voluntarily give up the CPU with thread_yield 



Ping Thread Pong Thread 




• What is the output of running these two threads? 
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threacLyieldf) 

• Wait a second. How does thread_yield() work? 

• The semantics of thread^yield are that it gives up the 
CPU to another thread 

♦ In other words, it context switches to another thread 

• So what does it mean for thread_yield to return? 

♦ it means that ano^/ier f/?read called thread_yieldl 

• Execution trace of ping/pong 

♦ pfintffpingVi"); 

♦ thread_yie!d(); 

♦ ;printffpong\n"); 

♦ thread_yield(); 

♦ . . . 
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Impleineiitiiig threaci_yield() 



thread_yield ( ) { 

throad_t old_thread = current_thr ead ; 
current_t:hread = got_noxt_throad ( ) ; 
append_t o_(iueue ( ready_(zueue , old_thread ) ; 
context_swi tch ( old_thread , current_thread ) ; 
return; 



The magic step is invoking con texLs witch () 
Why do we need to call append_to_queue()? 
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As old thread 



As new thread 



Thread Context Switch 



• The context switch routine does all of the nnagic 

♦ Saves context of the currently running thread (old_thread) 

» Push all machine state onto its stack (nof its TCB) 
:♦ Restores context of the next thread 

» Pop all machine state from the next thread's stack 

♦ The next thread becomes the current thread 

♦ Return to caller as new thread 

• This is all done in assembly language 

♦ It works at the level of the procedure calling convention, so it 
cannot be implemented using procedure calls 

♦ See code/threads/switch.s in Nachos 
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Preemptive Scheduling 

• Non-preemptive threads have to voluntarily give up CPU 

♦ A long-running thread will take. over the machine 

♦ Only voluntary calls to thread_yielcl(). thread.stopQ. or 
thread_exit() causes a context switch 

. Preemptive scheduling causes an involuntary context 
switch 

♦ Need to regain control of processor asynchronously 

♦ Use timer interaipt 

♦ Timer interrupt handler forces current thread to "call" thread_yield 

» How do you do this? 

♦ Nachos is preemptive 

» See use of thread->yleldOnRetum in code/machine/internjpt.cc 
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Threads Smnmaiy 

• The operating system is a large multithreaded program 

♦ Each process executes as a thread within the OS 

. Multithreading is also very useful for applications 

♦ Efficient multithreading requires fast primitives 

♦ Processes are too heavyweight 

• Solution is to separate threads from processes 

♦ Kennel-level threads much better, but still significant overhead 

♦ User-level threads even better, but not well integrated with OS 

• Now, how do we get our threads to correctly cooperate 
with each other? 

♦ Synchronization... 
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Next time... 


. Read Chapter 8: 8.6-8.23 




. Project #1 out 
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Lecture 4 (January 24, 2000) 



Reading 

Chapters 5 & 6 
The Process Control Block (PCB) 



WeVe already discussed several different types of hardware state that are associated with a process. In 
addition to the hardware-context, there is also the software-context of the process. This includes the state 
of the programs memory as well as the information that the operating systems maintains about each 
process. This information is stored in an operating system structure called the process control block 
(pcb). Among other things, the PCB contains the following: 



• The process ID of the process - a unique number that identifies or names the process within the 
operating system 

• The group ID - a number that identifies the group or classification of users to which the process 
belongs. 

• Information about open files 

• Accounting information (CPU time used, bytes read/written, &c) 

• Current state (BLOCKED, READY, RUNNING) (more later) 

• Linked lists and queue pointers (more later) 

• Exit status that is maintained for wait (more later) 



Student Question: Docs the PCB maintain scheduling information? 

Answer: Yes. It contains the process state, and perhaps accounting information that will affect its 
scheduling priority. Well talk more about scheduling soon. 

Process State Diagram 

You saw this diagram last class: 
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When a process exits, most of the process's resources are deleted. But the exit status is maintained in the 
PCB until the parent picks lip the status and deletes the PCB. A process is said to be a zombie, if the 
parent dies before it does. In this case, the init process will wait for the child and delete the PCB, 

There is a global variable, active, that keeps track of which process is currently running. 

The Ready Queue 

In most systems there is only one process, in others there are several procressors. In general, we assume 
that there can be many more processes that are ready to run than can actually run at any point in time. 

For this reason, we maintain a queue of ready processes. Our favorite way of implementing a queue is 
with a doubly linked list But there many different ways. In class, for simplicity. We'll just draw queues 
as singly linked lists. 























tr ■ — 





















One suhplo scheduling disciple involves selecting the active process by moving back and forth, round 
robin, through the ready list. Each process is selected, in turn, to become the active process. 

More about scheduling soon. 



the Blocked Queue 
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Generically, we can view the blocked state as consisting of a single blocked queue, containing all 
processes that are blocked ~ regardless of the reason. But actual systems implement a separate queue for 
each reason. 

For example, there is a separate queue for each terminal device, a separate queue for each process's 
inbound IPC, and a separate queue for each process's inbound IPC conmiunications. 

Lots of Pointers 

More sophisticated systems might have multiple ready queues in addition ot the multiple wait queues. 
Different ready queues could be used to contain different types of ready processes. 

It is also difficult to find the PCB from a PID, since there are many queues to search. 

The PCB for a process can actually be in multiple queues at the same time. 

The consequence is that real operating systems have lots of ugly pointers to implement these 
interconnected queues and other data structures. We'll draw them separately and neatly, but that is only 
so that the examples are clear. 

Switching Contexts 

Schedulers often change the running process. This is process requires a context switch. As you might 
Conclude by considering the amount of process-state that must be saved and restored, this is a very 
expensive process. 

So why would an operating system want to context switch? 

• Allow one proces to run while another is waiting for I/O 

• One process exits or otherwise terminates 

• The OS wants to prcempt a process to allow another process to run 

• The OS wants to give a newly created process priority 

• &c 

Context switches can only occur in kernel mode. This is because the lists, queues, and other resources 
;that=^must be affected during a context switch must alos be protected. 

The good news is that any time we might want to perform a context switch, we are already in kernel 
mode: 

> Interrupts signalling a change in an I/O device 

• Timer interrupts 

• System calls 

..ieach of these events (and many more) cause entry into the kernel mode. 
The Idle Process 

What happens when there are no user or system processes to run? Perhaps there is no useful work to do. 
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or all of the useful work is blocked for various reasons. 

Most systems run a special process called the idle process. 

Rhetorical Question: So, what can the idle process do? 
Student answer: Crack MP3. 

Instructor Answer: While this might be a useful thing, we actually can't do this. This could be run as low 
priority process. By defintion, the idle process only runs when nothing else can run. 

The semantics of this process are very simple: 

X GOTO X 

Since the purpose of this process is to occupy an idle CPU, when absolutely nothing else can fill that 
role, it is critical that this process can never block. And since this process achieves absolutely no useful 
work, it is critical that it not occupy the CPU when anything else can run. 

If we look at the semantics of the process (x GOTO x), it should be fairly easy to convince ourselves 
that this process can't block. 

Student Question: It looks like the only way out of this process is via an interrupt? But there's nothing 
happening, so one won't occur. And the program doesn't end. How do we get out? 

Answer: We don't want to get out until a new process is created and is runnable or an existing process is 
unblocked. Either requires that an interrupt is generated by an I/O device. The handler for the interrupt 
gets us out of the idle process and allows the scheduler to run. 

Student Question: Can't we perform system maintenance? 

Answer: Perhaps, but this cannot replace the idle process, because system maintenance processes can 
block. And the idle process must not block — the CPU is running, so it must do something. This type of 
task can be run with a very low priority, so that the only thing with a lower priority is the idle process. 
The only other option is to hard-code the scheduler to handle the special case of no runnable processes — 
the idle process is a much cleaner fix. 

Student Question: Can't we do better? Is there really nothing better? 

Answer: No, we can't do anything else -- never mind anything better. This is the universal requirement 
for the idle process to run. Anything useful might block. 

Student Question: What about powering down? 

Answer: This is the modem approach. Many systems do reduce power by slowing down the CPU. The 
idle process still loops — just more slowly. When something else can run, the CPU speed is restored. 
Some processors can power down and wake-up when an interrupt occurs. 

Student Question: What about polling I/O devices? Don't these want to poll while idle is running? 



Answer: 
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Modem systems don't actually implement or allow polling. Although a program might poll 
a device, the program is actually polling the software maintained state of the device. This 
state is actually maintained using interrupts. Consider the software instruction 

ioctl (fd, FIONREAD, &count) 

A program can use this to poll a device, it returns the number of characters ready to read. 
But the infomration accessed by this call is maintained via interrupts. The kernel never 
busy-waits; this is very inefficient. 

There are some very infrequent periodic events that might occur on the order of ever 
lOOmS. But this is very different the period is very wide and it isn't really polling. 

The other thing is that the idle proces might run 99.9% of the time or it might not run for 
weeks. There are no guarantees. Polling in the idle process is certainly not safe. 

Although the need for the idle process could be obviated by a special case in the scedule, this would 
mean not only special-case code, but also that the sceduler would need to be interruptable. The idle 
process is a better solution in the OS, because as with other software, it avoids a nasty special case. 

It can be implemented as a regular process with the lowest priority (reserved for idle), or with very 
simple special case code to ensure that no process is every added behind it in the ready queue. 

Student Question: The book talks about process aging. Won't this eventually force the idle process to 
run, even though other process are ready? 

Answer: The books speaks of aging processes. This means raising their priority over time to avoid 
starvation, regardless of the other facets of the scheduling discipline. If aging is used, the idle process 
a special case — it should not be aged. 

Threads, a.k.a Light- Weight Processes (L WP) 

Threads and light-weight processes are, in the context of operating systems, the same thing. Some 
vendors may assign special meanings to these terms, but this is vendor-specific. 

Consider the state of a process: PCB, memory, registers, &c. 

Now suppose that we want multiple process-like things that are separately schedulable ~ but share 
memory. 

Our model of processes and the OS currently looks like this: 
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Now consider multiple "processes" sharing the same memory, but otherwise maintaining different state 
(registers, &c). We call these processes within procesees threads. We call them this, because they are 
separate threads of control within the same process (actually, there is a slightly different term for this, 
but we won't introduce it). 

Instructor Question: Why would we want this? Why not just have separate address spaces? 

Student Answen We could have a multiprocessors and this could let us increase parallelism - multiple 
threads could run at the same time. 

Instructor response: True, but this doesn't justify threads. Multiple processes could run at the same time. 
Answer (from class and instructor): 

• Fast conmiunication: any thread can write to memory and any other thread can see it - without 
penalty. 

• Fast context switch: This actually depends on the implementation, but switching among threads 
within the same address space is faster than switching among processes in different address 
spaces. We don't need to save and restore the context, including the BASE and LIMIT registers, 
and other memory-managment registers, to context-switch. But depending on how the threads are 
implemented, the amount of other overhead can varyy: it can be very, very fast, or just somewhat 
faster. 

• A special cache, called the TLB doesn't need to be flushed to context switch among threads in the 
same address space. This not only saves the time it takes to flush the cache, but also maintains the 
utility of the cache -- thiis is a big win TLB misses are very expensive. 

• A process can do useful work, even while it is blocked: yes, but this also depends on the 
implementation. 



Kernel Supported Threads 
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We can think of kernel supported threads as a system where multiple PCBs can point to the same 
address space. Each PCB is really no longer a PCB, but more of a thread control block (TCB). But it is 
still usually called the PCB. 

The PCB now maintains the state of each thread and allows each thead to be scheduled independently. 
The PCB still holds the usual hardware state, queue state, pointer to address state, and a pointer to the 
task control block (TCB), 

What is a TCB (notice that we are referring to a task control block, not a thread control block)? It 
maintains the state that is not stored in the PCB — the state that applies to all threads. 

We call processes composed of more than one thread of control tasks, (This is the term we almost 
introduced earlier — it just slipped) 

This approach is consistent with the general computer science approach, "anything in computer science 
can be solved with an additional level of indirection." In this case the indirection via the TCB allows us 
to have both common and separate state for the threads. 



As the name implies, kernel supported threads require OS support. Many, but not all, OSs support kernel 
threads. 



User-level Threads 
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User-level threads are implemented via a user-level thread library. The kernel niether knows nor cares 
that they exist. From the kemers perspective, they are just regular code. User level threads require no 
changes to the kernel. 

TCBs are simply malloc'd each time that a thread is created and linked together to form queues ~ within 
the space of the process. 

Context switches among the threads are very cheap ~ neither the hardware nor the OS knows or cares 
about the context of the threads. Since we are not changing address spaces or process state, we are not 
changing any registers. The state of the threads is just part of the state of the process. This saves much 
overhead. 

Advantages of User-Level Threads 

Context switches are cheaper, since no kernel support is required and the state of the threads ispart of the 
state of the process. 

No kernel support is required, user threads can be implemented by user in older OSs that don't support 
kernel threads, or by more modem, but minimalist OSs that also don't support kernel threads. 

User-level threads can iniplement their own scheduling policy that may be a better fit that the OS 
process scheduling policy. 

Disadvantages of User-Level Threads 

If one thread blocks, all threads within the process are blcoked. Example: Reading from the terminal. 



Student Question: Can't the threads use non-blocking writes? 
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Answer: yes, if the programming is careful to use signal-based, non-blocking I/O. 

Student Question: How can preemptive scheduling occur without the timer interrupt? 

Answer: This can all be simulated within a thread. In this case, one way might be with SIGALRM. 

Student Question: Couldn't the threads just yield to each other? 

Answer: Yes, this could also work ~ since they, unlike processes, are cooperating by design. 
Combination: Kernel and User-level Threads? 

It is also possible to use a combination of user-level and kernel supported threads. One open research 
area involves determining exotic ways of balancing the use of both mechanisms. 

CPU Scheduling 

What are the goals of CPU scheduling? (This also applies to process scheduling and CPU scheduling) 



• decrease the overhead of context-switching 

• decrease the overhead of the scheduler itself 

o Trade-off: making scheduling decisions more often allows more optimal decisions, becuase 
the most up-to-date information is used. But running the scheduler frequently increases the 
overiiead of the scheduler itself. This is a tradeoff between scheduling fairness and and 
decreasing the overhead of the scheduler. 

• decrease response time 

• increase throughput 

Long-Term Scheduling 

Long-term schedulign answers the question, "Which jobs are admitted and when?" If too many jobs are 
scheduled, the system can begin to thrash as it spends more time sharing resources than accomplishing 
useful work. Good long term scheudling ensures that as many processes are run at a time as is possible, 
without overburdening the system. The goal is to make 100% utilization of resources by interleaving 
their use among processes - without making any resource (especially the CPU or memory) too scare to 
prevent thrashing (or less-sever perfomrance degradation). 

This is mostly used in batch systems, since, for example, we would never want login to return "Too 
many users - try again later." 

Short-Term Scheduling (a«k.a CPU scheduling) 

Short term schuling answers the question, which process gets the CPU. This question is particularly 
important, because the CPU is the most valuable resource in the system. 

Medium-Term Scheduling 

Medium-term scheduling is often implemented as part of memory management (chapter 8). 



http://www.andrewxmu.edu/course/15-412/ln/412springlecture4.htiT^ printed September 14, 2005 



Swapping, the movement of a parts of a process's memory to and from disk, to free available RAM, is 
really medium term scheduling. 

If too many processes are consuming too much memory, we keep moving back and forth to disk. It is 
very expensive to move the same pages to and from disk frequently. It might be better to run fewer 
processes and keep more of their memory available. 

The gola is to give processes the mimimum amount of memory that they need to run efficiently. We can 
also swap processes to disk when they block waiting for I/O. For example, the user doesn't need CPU 
while s/he is staring at a prompt wondering what to type. 

We'll talk about this topic in detail later. 

Back To CPU Scheduling 

There are many different types of scheduling. The first major distinction that we will draw is between 
preemptive policies and non-preemptive policies. 

Premptive approaches allow the scheduler to stop a running process and allow another process to run. 
With non-preemptive schuduling, once a process starts, it will only be stopped if it voluntarily yields or 
if it blocks. A stricter definition would require that it remain scheduled, even if it blocked. 

We'll start by discussing non-preemptive scheduling: 

pirst Come First Serve (FCFS) 

This is the "get in line approach." It is simple and in some sense fair. But long jobs can force short jobs 
to wait a long time. It may be desirable to run long jobs at night and short jobs during the day, or short 
jobs first. FCFS can't enforce system priorities. 

Shortest Job First(SJF) 

SJF scheduling runs the job that requires the least CPU first. How do we know which job this is? 

In the past, the progranmiers on batch systems were required to describe resource utilization on one for 
the first cards in the deck. If the over specified the CPU use, wasting CPU, they would be penalized by a 
lower priority. 

If they underestimated the CPU use, their job wouldn't finish and they would have to re-run the job. 
This provided incentive for good estimates. 

Now systems might estimate CPU time based on the type of program, the size of the input data set, &c. 
But these are just guesses. They might be wrong. 

This algorithm has the theoretical property that it has the minimal average waiting time across all 
prociesses (if the CPU time is estimated exactly). This is because the cost of a long job running first can 
penalize many small jobs. But if the small jobs run first, only one job is penalized. In other words, the 
same time penalty can be asmortized over more jobs, if shorter jobs are run first. 

But this algorithm is unfair and can lead to starvation. Longer jobs might never run, if shorter jobs keep 
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arriving. 

Priority Scheduling 

Priority, based schuling is a generalization of either SJF or FCFS. Priority based scheduling runs the 
highest priority jobs first. If we make shorter jobs a higher priority than larger jobs, it is SJF. If we make 
older a jobs higher prioirty than newer jobs, it is FCFS. 

The priority can be anything. It can be derived from an econimic model, for exmaple, the more you are 
willing to pay, the sooner your process will get scheduled. This is equivalent to paying for Fed. Ex 
instead of gorund shipping. 

Or perhaps it could be assigned based on other concerns. Perhaps President Cohen 's jobs get a higher 
priority than ours. 

Preemptive Scheduling Is More Interesting 

Premptive SJF 

A preemptive of SJF would allow the scheduling decision of a process to be re-evaluated based on new 
jobs that have arrived or based on the quality of the estimate. If a shorter job arived, it could be run. Or 
if the estimate proved to be inaccurate, and the expected completion time increased, another job might 
be selected to run. 

I/O and CPU bound jobs might be mixed to try to keep all of the I/O devices busy. Estimates could be 
made of the CPUAO burst cycle of the processes and they could be scheduled accordingly. These 
estimates can be adjusted based on past experience using averaging: 

Let Tq be the initial guess 

Let C J be the initial measured value 

Tj , the next guess can be computed as follows: 

Ti = (To + Ci)/2 

T^ = Tq alpha + Ci (1 - alpha) 

0< alpha <1 

Subsequent guess can be computed in a similar manner. 

This leads to an adaptive evolution of the idea of the CPU/IO burst cycle and an adaptive understanding 
of the process's priority. 
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MSDN Home > MSDN Library > Win32 and COM Development > System 
Services > DLLs. Processes and Threads > DLLs, Processes, and Threads > 
Processes and Threads 
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About Processes and Threads 

Each process provides the resources needed to execute a program. A 
process has a virtual address space, executable code, open handles to 
system objects, a security context, a unique process identifier, 
environment variables, a base priority, minimum and maximum working 
set sizes, and at least one thread of execution. Each process is started 
with a single thread, often called the primary thread, but can create 
additional threads from any of its threads. 

A thread is the entity within a process that can be scheduled for 
execution. All threads of a process share its virtual address space and 
system resources. In addition, each thread maintains exception handlers, 
a scheduling priority, thread local storage, a unique thread identifier, and 
a set of structures the system will use to save the thread context until it 
is scheduled. The thread context includes the thread's set of machine 
registers, the kernel stack, a thread environment block, and a user stack 
in the address space of the thread's process. Threads can also have their 
own security context, which can be used for impersonating clients. 

Microsoft® Windows® supports pree/npt/Ve multitasking, which creates 
the effect of simultaneous execution of multiple threads from multiple 
processes. On a multiprocessor computer, the system can simultaneously 
execute as many threads as there are processors on the computer. 

A Job object allows groups of processes to be managed as a unit. Job 
objects are namable, securable, sharable objects that control attributes 
of the processes associated with them. Operations performed on the job 
object affect all processes associated with the job object. 

A fiber is a unit of execution that must be manually scheduled by the 
application. Fibers run in the context of the threads that schedule them. 
Each thread can schedule multiple fibers. In general, fibers do not 
provide advantages over a well-designed multithreaded application. 
However, using fibers can make it easier to port applications that were 
designed to schedule their own threads. 

For more information, see the following topics: 

• Multitasking 

• Scheduling 

• Multiple Threads 

• Child Processes 
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Multiple Threads 

A thread is the entity within a process that can be scheduled for execution. All threads of 
a process share its virtual address space and system resources. Each process is started 
with a single thread; but can create additional threads from any of its threads. 

For more information, see the following topics: 

• Creatine Threads 

• Thread Stack Size 

• Thread Handles and Identifiers 

• Suspending Threa<1 Execution 

• Svnchronizino Execution of Multiple Threads 

• Multiple Threads and GDI Objects 

• Thread Local Storage 

• Creating Windows in Threads 

• Terminating a Thread 

• Thread Security and Access Rights 
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Creating Threads 

The CreateThread function creates a new thread for a process. The creating thread must 
specif/ the starting address of the code that the new thread is to execute. Typically, the 
starting address is the name of a function defined in the program code (for more 
information, see ThreadProc). This function takes a single parameter and returns a 
DWORD value. A process can have multiple threads simultaneously executing the same 
function. 

The following is a simple example that demonstrates how to create a new thread that 
executes the locally defined function, ThreadProc. The creating thread uses a dynamically 
allocated buffer to pass unique information to each instance of the thread function. It is 
the responsibility of the thread function to free the memory. 

The calling thread uses the WaitForMultipleObiects function to persist until all worker 
threads have terminated. Note that if you were to close the handle to a worker thread 
before it terminated, this does not terminate the worker thread. However, the handle will 
be unavailable for use in subsequent function calls. 

# include <windows.h> 
§ include <strsafe.h> 

Sdefine MAX_THREADS 3 
Sdefine BUF_SIZE 255 

typedef struct _>!yData ( 

int vail; 

int val2; 
} MYDATA, *PMYDATA; 

DWORD WINAPI ThreadProc ( LPVOID IpParam ) 
{ 

HANDLE hStdout; 
PMYDATA pData; 

TCHAR msgBuf{BUF_SIZEJ; 
si2e_t cchStringSize; 
DWORD dwChars; 

hStdout = GetStdHandle(STD_OUTPUT_HANDLE) ; 
if( hStdout == INVALID_HANDLE_VALUE ) 
return 1; 

// Cast the pareuneter to the correct data type. 

pData = ( PMYDATA )lpParam; 

. // Print the parameter values using thread-safe functions. 

StringCchPrintf (msgBuf , BUF_SIZE, TEXT ( "Parameters = %d, %d\nM, 

pData->vall, pData->val2) ; 
StringCchLength{msgBuf , BUF_SI2E, tcchStringSize) ; 
WriteConsole< hStdout, msgBuf, cchStringsize, fcdwChars, NULL) ; 

// Free the memory allocated by the caller for the thread 
// data structure. 

HeapFree (GetProcessHeap ( ) , 0 , pDa ta ) ; 
return 0; 



Exhibit G to 



Petition for Review by the PTO Director or his 
Authorized Delegate in Technology Center 2100 



Hewlett-Packard Documentation of Threads 



Petition re "New Matter" and Premature FinaJity 
This paper dated December 14, 2005 



114596-28-000053BS 



S/N 09/626,325 

3040925.3 



pthread(3T) 



(Pthread Library) 



pthread(3T) 



NAME 

pthread - Introduction To POSIX.lc Threads 
DESCRIPTION 

The POSIX.lc library developed by HP enables the creation of processes that can exploit application and 
multi-processor platform parallelism. The pthread library libpthread consists of over 90 standardized inter- 
faces for developing concurrent applications and synchronizing their actions within processes or between 
them. This manual page presents an overview of libpthread including terminology and how to compile and 
link programs which use threads. 

COMPILATION SUMMARY 

A multi- threaded application must define the appropriate POSIX revision level (199506) at compile time 
and link agednst the pthread library via -Ipthread. For example: 

cc -D_POSIX„C_SOt7RCE=199506L -o myapp myapp.c -Ipthread 

All program sources must also include the header file <pthread.li>. 

Note: When explicitly specifying ANSI compilation (via "-Aa"). defining the POSIX revision level restricts 
the program to using interfaces within the POSIX namespaces. If Interfaces in the larger X/Open 
namespace are to be called, either of the compiler options. -D__XOPEN_SOURCE_EXTENDED or 
-D_HPUX_SOURCE, must be specified in addition to -D_POSIX_C_SOURCE=199506L. Alternatively, 
compiling with -Ae (or not specifying *-A') will Implicitly specify -D_HPDX_SOURCE. 

Note: Some documentation will recommend the use of -D_REENTRANT for compilation. While this also 
functions properly, it is considered an obsolescent fonru 

THREAD OVERVIEW 

A thread is an independent flow of control within a process, composed of a context (which includes a regis- 
ter set and a program counter) and a sequence of instructions to execute. 

All processes consist of at least one thread. Multi-threaded processes contain several threads. All threads 
share the common address space allocated for the process. A program using the POSIX pthread APIs 
creates and manipulates what are called user threads, A kernel thread is a kemel-schedulable entity which 
may support one or more user threads. Currently, the HP-UX threads implementation supports only a 
one-to-one mapping between user and kernel threads. 

Each thread is assigned a unique identifier of type pthread_t upon creation. The thread id is a process- 
private value and implementation-dependent. It is considered to be an opaque handle for the thread. Its 
value should not be used by the application. 

NOTES ON INTERFACES 

The HP-UX system provides some non-standard extensions to the pthread API. These will always have a 
distinguishing suffix of _np or _NP (non-portable). 

The programmer should always consult the manpages for the functions being used. Some standard- 
specified functions are not available or may have no effect in some Implementations. 

THREAD CREATION/DESTRUCTION 

A program creates a thread using the pt;liread_create { ) functioa When the thread has completed its 
work, it may optionally call the pthread_exlt ( ) function, or simply return from Its Initial function. A 
thread can detea the completion of another by using the pthroad_ j oin ( ) functioa 

pthread_create ( ) Creates a thread and assigns a unique identifier. pthread_t. The caller provides 
a function which will be executed by the thread. Optionally, the call may expli- 
citiy specify some attributes for the thread (see PTHREAD ATTRIBUTES 
below). 

pthread_exit ( ) Called by a thread when it completes. This function does not return. 

p thread. join ( ) This is analogous to wait ( ) , but for pthreads. Any thread may join any other 
thread In the process, there is no parent/child relationship. It returns when a 
specified thread terminates, and the thread resources have been reaped. 

pthrGad_detach( ) Makes it unnecessary to "join' the thread. Thread resources are reaped by the 
system at the time the thread terminates. 
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PTHREAD ATTRIBUTES 

A set of thread attributes may be provided to pthread_create ( ) , Any changes from default vsilues 
must be made to the attribute set before the call to pthread_create ( ) is made. Subsequent changes 
to the attribute set do not affect the created thread. However, the attribute set may be used in multiple 
pthread_create ( } calls. 

Note that only the "detachstate", "schedparam*. "schedpoUcy", and 'processor' attributes of a thread may be 
effected subsequent to thread creation. However, this is done via the ptlir6ad_detach( ) . 
pthread_setschedparaiii( ) . andbthread processor bind np( ) functions, respectively. 

pthread_attr_ini t ( ) Initializes an attribute set for use in the pthread.create ( ) call. 

pthroad_attr_dos troy ( ) Destroys the content of an attribute set. 

pthread_attr_getdetachstate ( ) . 
pthread_attr_getguardslze ( ) , 
pthread_attr__getlnherltsched ( ) . 
pthread_attr_gotprocessor_np ( ) . 
pthread_attr __getschedparam( } , 
pthread_attr_getschedpollcy ( ) , 
pthread_attr_get scope ( ) . 
pthread_attr_get8tackaddr ( ) . 
pthread_attr_getstackslze ( ) ; 
.pthread_attr_setdetachstate ( ) , 
pthread_attr_setguardsize( ) ; 
pthread_attr_setinherit8ched( ) , 
pthread_attr_setprocessor_np ( ) . 
pthread_attr_setschedparaxa( } , 
pthread_attr_setschedpolicy ( ) , 
pthread_attr_set scope { ) . 
ptliread_attr_set stackaddr { ) . 
pthread_attr_8etstacksize ( ) 

These pthread_attr^et/8et<attribute>( ) functions get/set the associated attribute In 
the attribute set See the manpages for these functions for descriptions of the attributes. 

pthread_de£ault_8tack8lze_np ( ) 

This is used to set the default stacksize for threads created in subsequent attribute set initializations 
(calls to pthread_attr_init { ) ) or in ptliread_create ( ) where no attributes are supplied. 

CANCELLATION 

Certain applications may desire to terminate a particular thread without causing the entire process to exit. 
A thread may be canceled by another thread in the same process while the cancellation target thread exe- 
cutes a system call or particular library routine. 

When a thread issues a cancel request against another thread, the target thread can check to see if a 
request is pending against it via the pthread_testcancel ( ) interface. When called with a request 
pending, the target thread terminates after executing any cleanup handlers which may have been installed. 
Cleanup handlers may be used to delete any dynamic storage allocated by the canceled thread, to unlock a 
mutex. or other operations. 

Typically, the cancellation type for a thread is deferred. That is, cancellation requests are held pending 
until the thread reaches a cancelJationpoint which is simply one of a list of library functions and system 
calls (see lists below). 

The thread may set its cancellation type to asynchronous. In this case cancellation requests are acted upon 
at any time, llils can be used efifectively in compute-bound threads which do not call any functions that are 
cancellation points. 

pthread_cancel ( ) Cancel execution of a given thread. 

pthread_te8tc£uicel ( ) Called by a thread to process pending cancel requests. 

pthread_setcancel state () , 
. pthread_8etcajicel typeO 

Set the characteristics of cancellation for the thread. Cancellation may be enabled or disabled, or it 
may be synchronous or deferred. 
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pthread_cleanup_pop ( ) . 
pthread_cleanup_pu8h( ) 

Register or remove cancellation cleanup handlers. 

Cancellation points in the pthread library: 

pthread_testcancelO pthread_cond_waitO 
pthread_cond_timedwaitO pthreadJoinQ 

System functions which are always cancellation points: 



acceptO 


aio_suspendO 




connectO 


creatO 


dup20 


fsyncO 


getdirentriesO 


getmsgO 


getpmsgO 


ioctlO 


lockfO 


lockf640 


IseekO 


lseek640 


mq_receiveO 


mq_sendO 


msgrcvO 


msgsndO 


msyncO 


nanosleepO 


openO 


pauseO 


polio 


putmsgO 


putpmsgO 


readO 


readvO 


recvO 


recvfromO 


recvmsgO 


renameO 


selectO 


semopO 


sendO 


sendmsgO 


sendtoO 


sigsuspendO 


sigtimedwaitO 


sigwaitO 


sigwaitinfoO 


socketO 


systemO 


waitO 


wait30 


waitidO 


waitpidO 


writeO 


writevO 



* fcntl < ) is a cancellation point only with the F_SETIiK command. 

For the following Ubc functions, whether the thread is cancelled depends upon what action is performed 
while executing the function. If the thread blocks while inside the function, a cancellation point is created 
{i.e.. the thread may be cancelled). Note: Other libraries may have cancellation points. Check the associ- 
ated documentation for details. 



blcloseO 


blgetO 


biopenO 


blreadO 


blsetO 


catdoseO 


catgetsO 


catopenO 


closedirO 


closelogO 


creat640 


ctermldO 


cuseridO 


dbm_closeO 


dbm_deleteO 


dbm_fetchO 


dbm_firstkeyO 


dbm_nextkeyO 


dbm_openO 


dbm_storeO 


dbmcloseO 


endexportentO 


endfsentO 


endgrentO 


endhostentO 


endnetentO 


endnetgrentO 


endprotoentO 


endpwentO 


endserventO 


endutxentO 


fcloseO 


fflushO 


fgetcO 


fgetgrentO 


. fgetposO 


fgetpos640 


fgetpwentO 


fgetsO 


fgetwcO 


" fgetwsO 


fmtmsgO 


fopenO 


fopen640 


fjprintfO 


fputcO 


fputsO 


iputwcO 


^utwsO 


freadO 


fi-eopenO 


freopen640 


fsetposO 


fsetpos640 


ftellO 


fteUoO 


fteUo640 


ftwO 


ftw640 


fwriteO 


getcO 


getc_unlockedO 


getcharO 


getchar_unlockedO 


getcwdO 


getdateO 


getgrentO 


getgrgidO 


getgrgid_rO 


getgmamO 


. getgmam^rO 


gethostbyaddrO 


gethostbynameO 


. gethostentO 


getloginO 


getlogin_rO 


getoptO 


getpassO 
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getpwO 


getpwentO 


getpwnamO 


getpwnam_rO 


getpwutdO 


getpwuid_rO 


getsO 


getservbynameO 


getservbyportO 


getserventO 


gettxtO 


getusersheilQ 


getutentO 


getutidO 


getutlineO 


getutxentO 


getutxidO 


getutxlineO 


getwO 


getwcO 


getwchrO 


getwdO 


giobO 


grantptO 


iconv_closeO 


iconv_openO 


initgroupsO 


IckpwdfO 


mksCempO 


msem_lockO 


nftwO 


nftw20 


nfitw640 


nlistO 


open640 


opendirO 


openlogO 


pcloseO 


perrorO 


pfmtO 


popenO 


preallocQ 


prealloc640 


printfO 


putcO 


putc_unlockedO 


putcharO 


putchar.unlockedQ 


putpwentO 


putsO 


pututlineO 


pututxllneO 


putwO 


putwcO 


putwcharO 


putwsO 


readdirO 


readdlr_rO 


reaipathO 


removeO 


rewindO 


rewinddirO 


scandirO 


scanfO 


seekdirO 


setgrentO 


sethostentO 


setnetentO 


setnetgrentO 


setprotoentO 


setpwentO 


setserventO 


setusershellO 


setutentO 


setutxentO 


sigpauseO 


sleepO 


strerrorO 


syslogO 


tcdrainO 


tellO 


tmpfileO 


tmpme640 


tmpnamO 


ttynameO 


ttyname_rO 


ttyslotO 


ulckpwdfO 


ungetcO 


ungetwcQ 


usleepO 


vfprlntfO 


vfscanfO 


vprintfO 


vscanfO 


vsprintfO 


ysscanfO 


wordexpO 


wordfreeO 



NOTEl: The above functions may not be fully supported or may be considered obsolete. Consult individual 
manpages for more info. 

N0TE2: The list of cancellation points will vary from release to release. In general, if a function can return 
with an EIMTR error, chances are that it Is a cancellation point. 

SCHEDUIiING 

Threads may Individually control their, scheduling policy and priorities. Threads may also suspend their 
own execution, or that of other threads. Finally, threads are given some control over allocation of processor 
resources. 

jE»thread_8u spend ( } This function is used to temporarily stop the execution of a thread. 

pthread.contlnue ( ) , 
pthread_resu2n0_np ( ) 

These functions cause a previously suspended thread to continue execution. 

iPthre ad num -processor np ( ) , 
pthread_processor_blnd_np ( ) , 
ptliread_proces6or_id_np( ) 

These functions are used to interrogate processor configuration and to bind a thread to a specific pro- 
cessor. 

;ptlxread be t concurrency ( ) . 
^ptlxread_s et concur rency ( ) 

These functions are used to control the actual concurrency for unbound threads. 

p thr ead^e t schedpar am ( } . 
!^p thr ead_s e t schedpar am ( ) 
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These functions are used to manipulate the scheduling policy and priority for a thread. 

cched_got_priority_inax( ) . 
sched_get_priority_inin ( ) 

These functions are used to interrogate the priority range for a given scheduling policy. 

sched yield This function is used by, a thread to yield the processor to other threads of equal or 
greater priority. 

COMMUNICATION & SYNCHRONIZATION 

Multi-threaded applications concurrently execute instructions. Access to process-wide (or interprocess) 
shared resources (memory, file descriptors, etc.) requires mechanisms for coordination or synchronization 
among threads. The libpthread library offers synchronization primitives necessary to create a deterministic 
application. A multi-threaded application ensures determinism by forcing asynchronous thread contexts to 
synchronize, or serialize, access to data structures and resources managed and manipulated durli^ run- 
time. These are mutual-exclusion (mutex) locks, condition variables, and read-write locks. The HP-UX 
operating system also provides POSIX semaphores (see next section). 

Mutexes furnish the means to exclusively guard data structures from concurrent modification. Their proto- 
col precludes more than one thread which has locked the mutex from changing the contents of the pro- 
tected structure until the locker performs an analogous mutex unlock. A mutex can be initialized in two 
ways: by a call to pthread_ixiutox_inl t () ; or by assignment of PTHREAD_MUTEX_INITIALIZER. 

Condition Variables are used by a thread to wait for the occurrence of some event A thread detecting or 
causing such an event can signal or broadcast that occurrence to the waiting thread or threads. 

Read-Write locks permit concurrent read access by multiple threads to structures guarded by a read-write 
lock, but write access by only a single thread. 

pthread_imitex_inlt () , 
pthread_imite3c_destroy ( ) 

Initialize/destroy contents of a mutex lock. 

pthread_znutex_lock () , 
pthread_xnutex_trylock () , 
pthread_iiiutGX_unlock( ) 

Lock/unlock a mutex. 

pthread.iDutexJgetprioceiliRg ( ) . 
pthread.mutex.setprioceiling () 

Manipulate mutex locking priorities. 

pthread.imitexattr.init ( ) . 
pthread_jnutexattr_de5troy ( ) , 
pthread_jiiutexattr_getprioceiling () . 
ptliread_imitexattr_^etprotocol () , 
ptliread.iiiutexattr_getpshared () , 
pthread.mutexattr^ettype ( ) , 
.pthread_2iiutexattr„getspln_np ( ) . 
.pthread_inutexattr_8etprloceiling () . 
pthread_imitexattr_setprotocol ( ) , 
pthread_imitexattr_setpshared ( ) . 
pthread_iiuitexattr„isettype ( ) , 
pthread_inutexattr_setspin_np ( ) 

Manage mutex attributes used for pthread_inutex_init ( ) . Only the 'prioceillngf attribute can 
be changed for an exiting mutex. 

pthread_^iutex_getyield£req_np() . 
■Pthread mutex setyleldfreo np( ) 

These functions, together with the spin attributes, are used to tune mutex performance to the specific 
application. 

pthread_cond_init () . 
.pthread_cond_des troy { ) 
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Initializeydestroy contents of a read-write lock. 

pthroad_cond_signal ( ) . 
pthread_cond_broadcast ( ) . 
pthread.cond_tiittedwait ( ) . 
p throad_coiid_wal t ( ) 

Walt upon or signal occurrence of a condition variable. 

pthread_condattr_init ( ) , 
pthread_condattr_destroy { ) . 
pthread_condattr_getpshared( ) . 
pthread_condattr_setpshared ( ) 

Manage condition variable attributes used for pthroad_cond_lnlt ( ) . 

pthread_rwlock„lnlt ( ) . 
pthread_rwlock_dostroy ( ) 

InidaUze/destroy contents of a read-write lock. 

ptliread_rwioGk_rdlock ( ) . 
ptliread_rwlock_tryrdlock ( ) , 
pthread_rwlock_wrloGk ( ) . 
ptliread_rwlock„trywrlock { ) , 
pthread_rwlock_unlock ( ) 

Lock/unlock a read-write lock, 

.pthread_rwlockattr_init { ) , 
.ptliread_rwlockattr_destroy ( ) . 
pthread_rwlockattr_getpshared( ) , 
pthread_rwlockattr__setp8hared ( ) 

Manage read-write lock attributes used for pthroad_rwlock_init ( ) . 

POSIX l.b SEMAPHORES 

The semaphore functions specified in the POSIX 1 .b standard can also be used for synchronization in a mul- 
tithreaded application. 

sen^inlt ( ) . 
sem_destroy ( } 

Initialize/destroy contents of a semaphore. 

sent.walt ( ) , 
sen^trywait ( ) 

Increment/decrement semaphore value (possibly blocking). 

SIGNALS 

In a multithreaded process, all threads share signal actions. That is. a signal handler established by one 
thread is used in all threads. However, each thread has a separate signal mask, by which it can selectively 
block signals. 

Signals can be sent to other threads within the same process, or to other processes. When a signal is sent 
to the process, exactly one thread which does not have that signal blocked will handle the signal. When 
sent to a thread within the same process, that thread will handle the signal, perhaps later if the signal is 
blocked. Signals whose action is to terminate, stop, or continue will terminate, stop, or continue the entire 
process, respectively, even if directed at a particular thread. 

pthr ead_kl 1 1 ( ) Sends a signal to the given thread. 

pthread_sigskask ( ) Blocks selected signals for the thread. 

slgwait( ) . 
slgwaitlnf o ( ) . 

s i g t ixnedwal t ( ) These functions synchronously wait for ,given signals. 
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THREAD-SPECIFIC DATA 

Thread-specific data (TSD) is global data that is private or specific to a thread. Each thread has a different 
value for the same thread-specific data variable. The global ermo is a perfect example of thread-specific 
global data. 

Each thread-specific data item is associated with a key. The key is shared by all threads. However, when a 
thread references the key, it references its own private copy of the data. 

pthread_key_crQate ( } , 
pthread_key_destroy ( ) 

These functions manage the thread-specific data keys. 

pthread_get specific ( ) , 
pthread_8et specific ( ) 

These functions retrieve and assign the data value associated with a key. 

The HP-UX compiler supports a thread local storage (TLS) storage class. (This is not a POSIX standard 
feature.) TLS Is identical to TSD. except functions are not required to create/set/get values. TLS variables 
are accessed Just like normal global variables. TLS variables can be declared using the following syntax: 

thread int zyK; 

The keyword thread tells the compiler that zyx is a TLS variable. Now each thread can set or get 

TLS with statements such as: 

zyx = 21; 

Each thread will have a different value associated with zyx. 

TLS variables cannot be statically initialized, all are initially zero. Dynamically loaded libraries (via 
shipload ( ) ) cannot declare (but may use) TLS variables. 

TLS does have a cost in thread creation/termination operations, as TLS space for each thread must be allo- 
cated and zeroed, regardless of whether it ever will use the variables. If few threads actually use a large 
TLS area, it may be wise to instead use the POSIX TSD (above). 

REENTRANT LIBC & STDIO 

Because they return pointers to library-Internal static data, a number of libc functions cannot be used in 
multi-threaded programs. This is because calling these functions in a thread will overwrite the results of 
previous calls in other threads. Alternate functions, having the suffix _r (for reentrant, are provided 
within libc for threaded programming. 

Also, some primitives for synchronization of standard I/O operations are provided. 
asctixne_r() , 

ctiine_r () , ' 
getgrgid_t( ) . 
getgmanurO . 
getlogin_r(} , 
getpwnaiiL.r() , 
getpwuid_r ( ) , 
gmtime.t ( ) . 
local t ime^r () , 
rand^r () , 
readdir_r( ) , 
.atrtok_r () . 
ttynaine_r() 

Provide reentrant versions of previously existing libc functions. 

flockfileO. 
ftrylockf ile () . 
. f unlock ( ) 

Provide explicit synchronization for standard I/O streams, 

NaSCEIXANEOUS FUNCTIONS 

The section summarizes some miscellaneous pthread-related functions not covered in the preceding sec- 
tions. 



HP-UX Release Hi: December 20(K) 



-7- 



Section 3-637 



pthread(3T) 



(Pthread Library) 



pthread(3T) 



pthread_at£ork( ) Establish special functions to be called Just prior to and just subsequent to a 
£ork{) operation. 

pthread_egual ( ) Tests whether two pthread_t values represent the same pthread. 

pthread_once ( ) Executes given function just once in a process, regardless of how many threads 
make the same call. (Useful for one-time data initialization.) 

pthread_sel£ ( ) Returns identifier (pthread_t) of calling thread. 
THREAD DEBUGGING 

Debugging of multithreaded programs is supported in the standard HP-UX debugger, ddo. When any 
thread is to be stopped due to a debugger event, the debugger will stop all threads. The register state, 
stack, and data for any thread can be interrogated and manipulated. 

See the dde(l) manpage and built-in graphical help system for more information. 
TRACING FACELITIES 

HP-UX provides a tracing facility for pthread operations. To use it. you must link your application using 
the tracing version of the library: 

cc -D_POSIX_C_SOXJRCE=199506L -o myapp 2^yapp*c -lpthread_tr -Icl 

When the application is executed, it produces a pe|r-thread file of pthread events. This is used as input to 
the ttv thread trace visualizer facility available in the HP/PAK performance application kit 

There are environment variables defined to control trace data files: . 

THR_TRACE_DIR 

Where to place the trace data files. If this is not defined, the files go to the current working directory. 
THR_TRACE_SYNC 

By default, trace records are buffered and only written to the file when the buffer is full. If this vari- 
able is set to any non-NULL value, data is immediately written to the trace file, 

THH_TRACE_EVENTS 

By default all pthread events are traced. If this variable is defined, only the categories defined will be 
traced. Each category is separated by a The possible trace categories are: 

thread : cond : mut ex : rwlock 

For example, to only trace thread and mutex operations set the THR^TRACE_EVENTS variable to: 
thread :im2t:ex 

Details of the trace file record format can be found in / usr/ Include /8ys/trace_thr ead.h. 

See the Ctv(l) manpage and built-in graphical help system for more information on the use of the trace 
information. 

PERFORMANCE CONSIDERATIONS 

Often, an application is designed to be multithreaded to improve performance over its single-threaded coun- 
terparts. ^However, the multithreaded approach requires some attention to issues not always of concern in 
the single-threaded case. These are issues traditionally associated with the programming of multiprocessor 
systenis. 

The design must employ a lock granularity appropriate to the data structures and access patterns. 
Coarse-grained locks, which protect relatively large amounts of data, can lead to undeslred lock contention, 
reducing the potential parallelism of the application. On the other hand, employing very Ale-grained locks, 
which protect very small amounts of data, can consume processor cycles with too much locking activity. 

The use of thread-specific data (TSD) or thread-Iocalstorage (TLS) must be traded oflF, as described above 
(see THREAD^PECIFIC DATA). 

Mutex spin and yield firequency attributes can :be used to tune mutex behavior to the application. See 
pthreacLinutexattr_setspin_np{31) and pthread_mutex^setyieldfreq_np(Z\) for more Information. 

The default stacksize attribute can be set to Improve system thread caching behavior. See 
. pthread^default^stacksize_np{ZJ) for more information. 

Because multiple threads are actually running simultaneously, they can be accessing the same data from 
multiple processors. The hardware processors coordinate their caching of data such that no processor Is 
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using stale data. When one processor accesses the data (especially for write operations), the other proces- 
sors must flush the stale data from their caches. If multiple processors repeatedly readAvrite the same 
data, this can lead to cache-thrashing which slows execution of the instruction stream. This can also occur 
when threads access separate data items which Just happen to reside in the same hardware-cachable unit 
(called a cache line). This latter situation is called false-sharing which can be avoided by spacing data such 
that popular items are not stored close together. 

GLOSSARY 

The following definitions were extracted from the text ThreadTime by Scott J. Norton and Mark D. 
DiPasquale. PrenUce-Hall. ISBN 0-1^-190067-6, 1996. 

Application Progranuning Interface (API) 

An interface is the conduit that provides access to an entity or communication between entities. In the pro- 
gramming world, an interface describes how access (or communication) with a function should take place. 
Specifically, the number of parameters, their names and purpose describe how to access a function. An API 
is the facility that provides access to a function. 

Async-Cancel Safe 

A function that may be called by a thread with the cancelability state set to PTHR£AD_CANCEL_&NABZ<E 
and the cancelability type set to PTHR£AD_CANCEL_ASYNCHRONOns. If a thread is canceled in one of 
these functions, no state Is left in the function. These functions generally do not acquire resources to per- 
form the fiinction's task. 

Async-Signal Safe 

An async-signal safe function Is a function that may be called by a signal handler. Only a restricted set of 
functions may safely be called by a signal handler. These functions are listed in section 3.3.1.3 of the 
P0SIX.1C standard. 

Asynchronous Signal 

An asynchronous signal is a signal that has been generated due to an external event. Signals sent via 
kill ( ) and signals generated due to timer expiration or asynchronous I/O completion are all examples of 
asynchronously generated signals. Asynchronous signals are delivered to the process. All signals can be 
generated asynchronously. 

Atfork Handler 

Application-provided and registered functions that are called before and after a fork ( ) operation. These 
functions generally acquire all mutex locks before the fork ( ) and release these mutex locks in both the 
parent and child processes after the fork () . . 

Atomic Operation 

An operation or sequence of events that is guaranteed to complete as if it were one instruction. 
^Barrier 

A synchronization primitive that causes a certain number of threads to wait or rendezvous at specified 
. points In an application. Barriers are used when a application needs to ensure that all threads have com- 
pleted some operation before proceeding onto the next task. 

Botind Thread 

A user thread that is direcdy bound to a kernel-scheduled entity. These threads contain a system schedul- 
ing scope and are scheduled dlrectiy by the kernel. 

Cache Thrashing 

Cache thrashing is a situation In which a thread executes on different processors, causing cached data to be 
moved to and from the different processor caches. Cache thrashing can cause severe performance degrada- 
tion; 

Cancellation Cleanup Handler 

An application-provided and registered function that is called when a thread is canceled. These functions 
generally perform thread cleanup actions during thread cancellation. These handlers are similar to signal 
handlers. 
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Condition Variable 

A condition variable is a synchronization primitive used to allow a thread to wait for an event. Condition 
variables are often used in producer-consumer problems where a producer must provide something to one 
. or more consumers. 

Context Switch 

The act of removing the currently running thread from the processor and running another thread. A con- 
text switch saves the register state of the currently running thread and restores the register state of the 
thread chosen to execute next. 

Critical Section 

A section of code that must complete atomically and uninterrupted. A criticfd section of code is generally 
one in which some global resource (variables, data structures, linked lists, etc.) is modified. The operaUon 
being performed must complete atomically so that other threads do not see the critical section in an incon- 
sistent state. 

Deadlock 

A deadlock occurs when one or more threads can no longer execute. For example, ttiread A holds lock 1 and 
is blocked on lock 2. Meanwhile, thread B holds lock 2 and Is blocked on lock 1. Threads A and B are per- 
. manently deadlocked. Deadlocks can occur with any number of resource holding threads. An interactive 
deadlock involves two or more threads. A recursive (or self) deadlock involves only one thread. 

Detached Thread 

A thread whose resources are automatically released by the system when the thread terminates. A 
detached thread cannot be Joined by another thread. Consequently, detached threads cannot return an exit 
. status. 

Joinable Thread 

A thread whose termination can be waited for by another thread. Joinable threads can return an exit status 
to a Joining thread. Joinable threads maintain some state after termination until they are Joined by another 
. - thread. 

Kernel Mode 

A mode of operation where all operations are allowed. While a thread is executing a system call it is execut- 
ing in kernel mode. 

.Kernel Space 

The kernel program exists in this space. Kernel code is executed in this space at the highest privilege level. 
In general, there are two privilege levels: one for user code (user mode) and the other for kernel code (ker- 
nel mode). 

'Kernel Stack 

When a thread makes a system call, it executes in kernel mode. While in kernel mode, it does not use the 
, stack allocated for use by the application. Instead, a separate kernel stack is used while in the system call. 
, Each kernel-scheduled entity, whether a process, kernel thread or lightweight process, contains a kernel 

stack. See Stack for a generic description of a stack. 

Kernel Thread 

V Kernel threads are created by the thread functions in the threads library. Kernel threads are kernel- 
scheduled entities that are visible to the operating system kernel. A kernel thread typically supports one. or 
more user threads. Kernel threads execute kernel code or system calls on behalf of user threads. Some sys- 
tems may call the equivalent of a kernel thread a lightweight process. See Thread for a generic description 
of a thread. 

Lightweight Process 

A kerneUscheduled entity. Some systems may call the equivalent of a lightweight process a kernel thread. 
Each process contains one or more lightweight process. How many lightweight processes a process contains 
depends on whether and how the process is multithreaded. See Thread for a generic description of a 
■■• thread. 
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Multiprocessor 

A system with two or more processors (CPUs). Multiprocessors allow multithreaded applications to obtain 
true parallelism. 

Multithreading 

A programming model that allows an application to have multiple threads of execution. Multithreading 
allows an application to have concurrency and parallelism (on multiprocessor systems). 

Mutex 

A mutex is a mutual exclusion synchronization primitive. Mutexes provide threads with the ability to regu- 
late or serialize access to process shared data and resources. When a thread locks a mutex. other threads 
trying to lock the mutex block until the owning thread unlocks the mutex. 

POSK 

Portable Operating System Interface. POSIX defines a set of standards that multiple vendors conform to in 
order to provide for application portability. The Pthreads standard (POSIX 1003.1c) provides a set of port- 
able multithreading APIs to application developers. 

Priority Inversion 

A situation where a low-priority thread iias acquired a resource that is needed by a higher priority thread. 
As the resource cannot be acquired, the higher priority thread must wait for the resource. The end result is 
that a low-priority thread blocks a high-priority thread. 

Process 

A process can be thought of as a container for one or more threads of execution, an address space, and 
shared process resources. All processes have at least one thread. Each thread in the process executes 
within the process* address space. Examples of process-shared resources are open file descriptors, message 
queue descriptors, mutexes, and semaphores. 

Process Control Block (PCB) 

This structure holds the register context of a process. 

Process Structure 

The operating system maintains a process structure for each process in the system. This structure 
represents the actual process internally in the system, A sample of process structure information Includes 
the process ID, the process* set of open files, and the signal vector. The process structure and the values 
contained within it are part of the context of a process. 

Program Counter (PC) 

The program counter is part of the register context of a process. It holds the address of the current Instruc- 
tion to be executed. 

:Race Condition 

When the result of two or more threads performing an operation depends on unpredictable timing factors, 
this is a race condition. 

Read-Write Lock 

A read-write lock is a synchronization primitive. Read-write locks provide threads with the ability to regu- 
late or serialize access to process-ishared data and resources. Read-write locks allow multiple readers to 
concurrently acquire the read lock whereas only one writer at a time may acquire the write lock. These 
locks are useful for shared data that is mostly read and only rarely written. 

Reentrant Function 

A reentrant function is one that when called by multiple threads, behaves as if the function was called seri- 
ally, one after another, by the different threads. These functions may execute in parallel. 

Scheduling Allocation Domain 
The set of processors on which a thread is scheduled; The size of this domain may dynamically change over 
time. Threads may also be moved from one domain to another. 



HP-UX Release iii: December 2000 



-il- 



Section 3-641 



pthread(3T) 



(Pthread Library) 



pthread(3T) 



Scheduling Contention Scope 
The scheduling contention scope defines the group of threads that a thread competes with for access to 
resources. The contention scope is most often associated with access to a processor. However, this scope 
may also be used when threads compete for other resources. Threads with the system scope compete for 
access to resources with all other threads in the system. Threads with the process scope compete for access 
to resources with other process scope threads in the process. 

Scheduling Policy 

A scheduling policy Is a set of rules used to determine how and when multiple threads are scheduled to exe- 
cute. The scheduling policy also determines how long a thread is allowed to execute. 

Scheduling Priority 

A scheduling priority Is a numeric priority value assigned to threads in certain scheduling policies. Threads 
with higher priorities are given preference when scheduling decisions are made. 

Semaphore 

A semaphore is similar to a mutex. A semaphore regulates access to one or more shared objects. A sema- 
phore has a value associated with it. The value is generally set to the number of shared resources regulated 
by the semaphore. When a semaphore has a value of one, It Is a binary semaphore. A mutex is essentially a 
binary semaphore. When a semaphore has a value greater than one, it is known as a counting semaphore. 
A counting semaphore can be locked by multiple threads simultaneously. Each time the semaphore is 
locked, the value is decremented by one. After the value reaches zero, new attempts to lock the semaphore 
cause the locking thread to block until the semaphore is unlocked by another thread. 

Shared Object 

A shared object is a tangible entity that exists in the address space of a process and is accessible by all 
threads within the process. Iii the context of multithreaded programming, •shared objects* are global vari- 
ables, file descriptors, and other such objects that require access by tlireads to be synchronized. 

Signal 

A signal is a simplified IPC mechanism that allows a process or thread to be notified of an event. Signals 
can be generated synchronously and asynchronously. 

Signal Mask 

A signal mask determines which signals a thread accepts and which ones are blocked from delivery. If a 
synchronous signal is blocked from delivery, it is held pending until either the thread unblocks the signal or 
the thread terminates. If an asynchronous signal delivered to the process is blocked from delivery by a 
thread, the signal may be handled by a different thread in the process that does not have the signal 
blocked. 

Signal Vector 

A signal vector is a table contained in each process that describes the action that should be taken when a 
signal is delivered to a thread within the process. Each signal has one of three potential behaviors: ignore 
the signal, execute a signal-handling function, or perform the default action of the signal (usually process 
termination). 

Single-Tlireaded . 

means tiiat there is only one flow of control (one thread) through the program code; only one instruction is 
executed at a time. 

Spinlock 

A synchronization primitive similar to a mutex. If the lock cannot be acquired, instead of blocking, the 
thread wishing to acquire the lock spins in a loop until the lock can be acquired. Splnlocks can be easily 
used improperly and can severely degrade performance if used on a single processor system. 

Spurious Wakeup 

A spurious wakeup occurs when a thread is incorrecdy unblocked, even though the event it was waiting for 
has not occurred. A condition wait that is interrupted and returns because the blocked thread received a 
normal signal is an example of a spurious wakeup. 
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Stack 

A stack is used by a thread to make function calls (and return from those calls), to pass arguments to a 
function call, and to create the space for local variables when in that function call. Bound threads have a 
user stack and a kernel stack. Unbound threads have only a user stack. 

Synchronous Signal 

A synchronous signal is a signal that has been generated due to some action of a specific thread. For exam- 
ple, when a thread does a divide by zero, causes a floating point exception, or executes an illegal instruc- 
tion, a signal is generated synchronously. Synchronous signals are delivered to the thread that caused the 
signal to be sent. 

Tradltional Process 
This is a single-threaded entity that can be scheduled to execute on a processor. 

Thread 

A thread is an independent flow of control within a process, composed of a context (which includes a regis- 
ter set and program counter) and a sequence of instructions to execute. 

Thread Local Storage (FLS) 
Thread local storage is essentially thread-specific data requiring support from the compilers. With 1LS, an 
application can allocate the actual data as thread-specific data rather than using thread-specific data keys. 
Additionally, TLS does not require the thread to make a function call to obtain thread-specific data. The 
thread can access the data directly. 

Thread-Safe Fimction 

A thread-safe function is one that may be safely called by multiple threads at the same time. If the function 
accesses shared data or resources, this access is regulated by a mutex or some other form of synchroniza- 
tion. 

Thread-Specific Data CTSD) 
Thread-specific data is global data that is specific to a thread. All threads access the same data variable. 
However, each thread has its own thread-specific value associated with this variable, ermo is an example of 
thread-specific data. 

Itiread Structure 

The operating system maintains a thread structure for each thread in the system. This structure represents 
the actual thread internally in the system. A sample of thread structure information includes the thread 
IDi the scheduling policy and priority, and the signal mask. The thread structure and the values contained 
within it are part of the context of a thread. 

User Mode 

A mode of operation where a subset of operations are allowed. While a thread is executing an applications 
code, it is executing in user mode. When the thread makes a system call, it changes modes and executes in 
kernel mode until the system call completes. 

User Space 

The user code exists in this space. User code is executed in this space at the normal privilege level. In gen- 
eral, there are two privilege levels: one for user code (user mode) and the other for kernel code (kernel 
mode). 

'User Stack 

When a thread is executing code in user space, it needs to use a stack to make function calls, pass parame-. 
ters, and create local variables. While in user mode, a thread does not use the kernel stack. Instead, a 
separate user stack is allocated for use by each user thread. See Stack for a generic description of a stack. 

User Thread 

When pthread.create ( ) is called, a user thread is created: Whether a kernel-scheduled entity (kernel 
thread or lightweight process) is also created depends on the user thread's scheduling contention scope. 
When a bound thread is created, both a user thread and a kernel-scheduled entity are created. When an 
unbound thread is created, generally only a user thread is created. See Thread for a generic description of a 
thread. 
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ThreadTimehy Scott J. Norton and Mark D. DiPasquale. Prentice-Hall. ISBN 0-13-190067-6. 1996. 
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Introduction 

Multithreading is a popular programming and execution model that allows multiple threads to 
exist within the context of a single process, sharing the process' resources but able to execute 
independently. The threaded programming model provides developers with a useful abstraction 
of concurrent execution. However, perhaps the most Interesting application of the technology Is 
when it is applied to a single process to enable parallel execution on a multiprocessor system. 

Multithreading is not new to the Solaris" Operating Environment (OE). Threads have played 
an important part in enabling Sun to deliver successful, scalable, multiprocessor systems. The 
threading capabilities in the Solaris OE are continually being improved, and the Solaris 9 Operat- 
ing Environment contains Innovations for multithreaded applications — chiefly, the adoption of a 
highly tuned and tested "irl" thread model in preference to the historic "MxN" implementation. 

The goal of this paper is to describe the new threads implementation and encourage its use. 
It begins by providing historical context and recent developments. A technical audience with prac- 
tical experience of multithreading in the C or java" programming languages or similar environ- 
ments is assumed. For additional reading on the subject, '^Programming with Threads" is highly 
recommended for novice and expert alike. 

A Decade of Change 

Many changes occurred during the first ten years that Sun provided support for multithreaded 
applications: 

• System size (in terms of CPUs and memory) saw exponential growth 

• Multithreaded programming techniques evoked and matured 

• Application programming interfaces for threads became standardized 
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• Threads became ubiquitous in modern operating systems 

• Use of the inherently threaded Java programming language became widespread 

• Threaded applications became the norm, not the exception 

Clearly, the most significant development has been moving multithreading from theory into 
practice. Along the way, the multithreaded computing landscape has changed. Factors which 
seemed important lo years ago may be irrelevant today, and issues which were once considered 
on the fringe are now commanding the full attention of developers. 

Responding to Change 

The Solaris OE has always moved with the times, and a great deal has been done to Improve 
the scalability of threads within the kernel. This has led to exciting, and sometimes surprising, 
innovations. One such innovation is the move away from the original MxN model to a i:i 
implementation. 

Simply a Better Implementation 

The Solaris 8 OE introduced an alternate implementation based on the i:i model which leveraged 
the improvements in kernel threading directly at the process level The i:i implementation was 
simpler to develop, and its code paths were generally more efficient than those of the old imple- 
mentation. In the Solaris 8 OE, the MxN implementation remains the default. Users have tested 
the new i:i implementation, and many have adopted It. Again^ this Is not to say that a good 
implementation of the MxN model is impossible, but simply that a good i:i implementation is 
probably sufficient. 



Note - This paper does not attempt a discussion of the relative merits of the MxN and i:i 
threading models. The basic thesis is that the quality of an implementation is often more Impor- 
tant. 



Scalable Threaded Applications 

New programming technologies often go through an early period of upheaval as developer com- 
munities begin to separate theory from practice. Initial naivete is tempered by realism and experi- 
ence. Witness the history of the |ava~ programming language: the initial focus on browsers and 
not-so4hin-client applications has matured, broadened, and shifted to embrace just about every 
. level of computing — from consumer products to the data center. Multithreading has seen a sim- 
ilar evolution, and one of the shifts in emphasis has been away from "threads for everything" to 
"threads for scalability." 

For example, developers used to believe that a threads stack was an ideal place to store appli- 
cation session state. However, experience has proved that it is generally better to hold session 
state in well-designed data structures, and deploy a worker thread pool to deliver scalable, pre- 
dictable performance. 
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Preface 

Intended Audience 



This guide is for system and application programmers who use DECthreads to create multithreaded applications or to cn 
safe code libraries that can be called from'single-threaded or multithreaded applications. 
Document Structure 



This guide consists of the following: 



Parti 



Chapter 1 provides a brief overview of multithreaded programming. 
Chapter 2 discusses the concepts and techniques related to DECthreads. 

Chapter 3 describes thread disciplines and coding Issues you may face when writing a multithreaded program. 
Chapter 4 addresses writing thread-safe libraries. 

Chapter 5 introduces and provides conventions for the modular use of the DECthreads exception package. 
Chapter 6 contain^ an example demonstrating how to call DECthreads routines from a C language program. 

Part 2 

• This part provides detailed reference Information on each pthread interface routine. Routine descriptions appear 
alphabetical order by routine name. 

Part 3 



• This part provides detailed reference infonmation on each tis interface routine. Routine descriptions appear in alp 
order by routine name. 

Part 4 - Appendixes i, 

. • Appendix A discusses DECthreads issues and restrictions specific to Compaq's DIGITAL UNIX systenr^. 

• Appendix B discusses DECthreads issues and restrictions specific to OpenVMS systems. 

• Appendix C discusses DECthreads issues and restrictions specific to the Microsoft Win32 interfaces on Windows 
systems. 

• Appendix D discusses debugging issues for a multithreaded program that uses DECthreads. 

• Appendix E summarizes the differences between the Compaq proprietary DECthreads CMA (or cnria) interface ai 
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DECthreads pthread interface. Use this appendix to help you migrate your programs and applications to the pthi 
interface. 

• A ppendix F summarizes the differences between the DECthreads POSIX 1003.4a/Draft 4 (or d4) interface and th 
DECthreads pthread interface. Use this appendix to help you migrate your programs and applications to the pthr 
interface. 

Glossary 

• The Glossary contains definitions of terms used in this guide, listed alphabetically. 
Related Documents 

For additional infonmation on the Open Systems Software Group (OSSG) products and services, access the following Of 
World Wide Web address: 



http://www.openvins.digital.coin 

Reader's Comments 

Compaq welcomes your comments on this manual. 

Print or edit the online fomi SYS$HELP:0PENV1^SD0C_C0MMENTS.TXT and send us your comments by: 



Internet 



Fax 



Mail 



writer® dceidl.enet.dec.com 



603 884-0120, Attention: Core Technology Group, ZK02-3/Q18 



Core Technology Group, ZK02-3/Q1 8 
110 Spit Brook Rd. 
Nashua. NH 03062-2698 



How To Order Additional Documentation 

Use the following Worid Wide Web address to order additional documentation: 



http: //www, openvms .digital .com: 81/ 

If you need help deciding which documentation best meets your needs, call (800-282-6672). 
Conventions 

VMScluster systems are now referred to as OpenVMS Cluster systems. Unless otherwise specified, references to Open^ 
Clusters or clusters in this document are synonymous with VMSclusters. 





A horizontal ellipsis in examples indicates one of the following possibilities: 

• Additional optional arguments in a statement have been omitted. 

• The preceding item or items can be repeated one or more times. 

• Additional parameters, values, or other information can be entered. 




A vertical ellipsis indicates the omission of items from a code example or command format; the iter 
omitted because they are not important to the topic being discussed. 


0 


In command format descriptionis, parentheses indicate that you must enclose the options in parent! 
you choose more than one. 


[] 


In command format descriptions, brackets indicate optioned elements. You can choose one, none, • 
options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file 
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specification or in the syntax of a substring specification In an assignment statement.) 


[I] 


In command fomiat descriptions, vertical bars separating Items inside brackets indicate that you ch 
none, or more than one of the options. 


{} 


In command format descriptions, braces Indicate required elements; you must choose one of the o 
listed. 


text style 


This text style represents the introduction of a new term or the name of an argument, an attribute, ( 
reason. 

In the HTML version of this document, this convention appears as italic text. 


italic text 


Italic text indicates important information, complete titles of manuals, or variables. Variables includ< 
information that varies in system output (Internal error numbei), in command lines (/PRODUCER= 
and in command parameters In text (where dd represents the predefined code for the device type). 


UPPERCASE 
TEXT 


Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation 
system privilege. 


Monospace type 


Monospace type indicates code examples and Interactive screen displays. 

In the C programming language, monospace type in text identifies the following elements: keyword 

namoc f\f inrtononrtontiv/ r^mmniloH ovtomnt fiin/^tifMic onH fitoc ct/nfftv ciimmorioc £>nrl raforoo^oc f. 
flcHIIco \Jl IIIUcpci lUci luy LrUlll|Jllcu OAlclllal lUIIUUUlio dllU llico, oyillcIA oUIIUilaMco, cItiU lolefciluoo t 

or Identifiers introduced In an example. 




A hyphen at the end of a command fonmat description, command line, or code tine indicates that th 
command or statement continues on the following line. 


numbers 


All numbers in text are assumed to be diecimal unless otherwise noted. Nondecimal radixes— binai 
hexadecimal—are explicitly indicated. 



Parti 

DECthreads Overview and Programming Guidelines 

Part 1 contains chapters that provide an overview and concepts of DECthreads as well as defining programming disciplir 
guidelines for writing a multithreaded program.. 



Chapter 1 

Introducing DECthreads for Multithreaded Programming 

This chapter introduces the concepts of threads and multithreaded programming. It describes four functional models that 
basis for constructing multithreaded applications. The concepts and techniques Introduced here are described in more di 
Chapter 2 and in this guide's platfonrn-specific appendixes. 

This chapter's last section introduces the components of the DECthreads package, In particular the pthread and tis intei 
how those components support building multithreaded applications and tiiread-safe libraries. 
1 .1 Advantages of Using Threads 

Multithreaded programming means organizing and coding a program so that Instances of Its routines, called threads, c 
concurrentiy in ttie same process. You use threads to Improve a program's perfonnance— that is, its throughput, comput 
speed, responsiveness, or some combination. 

Using threads can improve a program's perfonnance on uniprocessor systems by pennitting the overiap of input, output, 
slow operations with computational operations. Threads are useful in driving slow devices such as disks, networics, temni 
printers. A multithreaded program can perform other useful wortc while waiting. for the device to produce its next event, si 
completion of a disk transfer or the receipt of a packet from the networie 

Using threads can also be advantageous when constructing an application's user interface.. Consider the typical arrangei 
window system. Each time the user invokes an action (for example, by clicking on a mouse button), the program can use 
tfiread to implement the action. If the user invokes multiple actions, multiple threads can perfonn the actions in parallel. 
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Using threads is especially advantageous when building a distributed system. These systems frequently contain a shares 
server, where the server sen^ices requests from multiple clients. Using multiple threads allows the server to handle client 
in parallel, instead of artificially serializing them or creating (at great expense) one server process per client. 

A program with multiple threads can be especially suited to run on a multiprocessor system, where threads run concurrei 
separate processors. Threads created using the DECthreads library are capable of utilizing multiprocessors, if the target 
supports parallelism within a process. Compaq's DIGITAL UNIX platfomns and OpenVMS Alpha platfomis support paralh 
OpenVMS VAX platfonm does not support parallelism. 
1 .2 Overview of Threads 

A thread is a single, sequential flow of control within a process. Within each thread there is a single point of execution. N 
traditional programs execute as a process with a single thread. Rqure 1-1 and Rgure 1-2 show the differences between 
threaded process and a multithreaded process. 

Figure 1-1 Single-Threaded Process 




ZK-3913A^GE 



In Figure 1-2 , notice that multiple threads share heap storage, static storage, and code but that each thread has Its own i 
and stack. 

Using DECthreads, Compaq's multithreading run-time library, a programmer can create several threads within a process 
^process's threads execute concurrently. Within a multithreaded program there are at any tinie multiple points of executip 

Threads execute within (and share) a single address space; therefore, a process's threads can read and write the same 
locations. When the threads access the same memory locations, your program must use synchronization elements, sucl- 
mutexes and condition variables, to ensure that the shared memory is accessed correctly. DECthreads provides routines 
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you to use these and other synchronization objects. Section 2.4 describes the synchronization objects that DECthreads ( 
well as the operations your program can perform on them. 



Figure 1-2 Multithreaded Process 
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1 .3 Thread Execution 

You should design and code a multithreaded program with the assumption that Its threads execute simultaneously. That 
program cannot make assumptions about the relative start or finish times of its threads or the sequence in which they ex 
These are govemed by the DECthreads thread scheduler, part of the run-time environment that DECthreads establishes 
program begins running. Nevertheless, your program can influence how DECthreads schedules its threads, by setting e£ 
scheduling policy and scheduling priority. ( Section 2.3.6 describes how thread scheduling works.) 

Each thread has its own thread identifier, which distinguishes it from all other threads in the process. In addition to the th 
scheduling policy and scheduling priority, each thread is associated with any thread-specific instances of thread-commor 
objects and with thread-specific system resources to support a flow of control. 

A thread changes its state over the course of its execution. A thread is in one of the following states: 

• Waiting—The thread is not eligible to execute, because it is synchronizing with another thread or with an external 
as I/O. 

• Ready-'The thread is eligible to be executed by a processor. 

• Running— The thread is cunently being executed by a processor. 

• Tenminated— The thread has completed ali of its woric or has been canceled. 



Rqure 1-3 shows the transitions between states for a typical thread implementation. 



http://h71000.www7.hp.eom/doc/72finaI/6493/6101pro.html# intro_threads_chap printed September ... 



Rgure 1-3 Thread State Transitions 



Waning 




Ready 




Running 




Temnkiated 


— m 


^ — r 






ZK-37e6A-GE 



Note 



Building your multithreaded program must produce executable code that is reentrant. Therefore, 
be sure that your compiler generates reentrant code before you design or code your multithreaded 
program. By default, Compaq's C, C++, Ada, Pascal, and BLISS compilers generate reentrant 

code. 

If you cannot build your program so that its executable code is reentrant, it might be impossible to 
keep the program's threads from interfering with each other. See Section 3.9.1 for more 
Information about thread-reentrant libraries. 

In general, when using threads, be aware of language-based programming practices that are 
inherently not thread safe. ("Thread safety" is explained in Section 3.9.2 .) You must address these 

factors when writing multithreaded applications and thread-safe libraries. For example, Fortran 
language routines typically rely heavily upon static storage, which can prevent those routines from 

being thread safe. 

1 .4 Functional Models for Multithreaded Programming 

The following sections describe four functional models of processing information that are especially well suited for impler 
multithreaded programs: 

• Boss/worker model 

• Wori^ crew model 

• Pipelining model 

• Combination of models 



1.4.1 Boss/Worker Model 

In a boss/worker model, one thread functions as the "boss" because it assigns tasks for "woricer" threads to perform. Eac 
perfonns a distinct task until it has finished, at which point it notifies the boss that it is ready to receive another task. Altei 
the boss polls workei^ periodically to see whether any is ready to receive another task. 

A variation of the tK)ss/worker model is the work queue modeL The boss places tasks in a queue, and workers check the 
take tasks to perform. 

An example of the work queue model in an office environment is a secretarial typing pool. The office manager boss puts 
to be typed in a basket, and worker typists take documents from the basket to work on. 

1 .4.2 Work Crew Model 

In the work crew model, multiple threads wori< together on a single task. The task is divided into pieces that are performe 
parallel, and each thread performs one piece. 

An example of a woric crew is a group of people cleaning a building. Each person cleans certain rooms or performs certa 
wori^ (washing floors, polishing furniture, and so forth), and each worics independently. 

In a multithreaded program that reflects the work crew model, each thread executes a task that can be performed in par£ 
1-4 shows a task performed by three threads in a woric crew model. 
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Figure 1-4 Work Crew Model of Thread Operation 
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1 .4.3 Pipelining Model 



In the pipelining model, a task is divided into steps. The steps must be performed in sequence to produce a single instan 
desired result, and the work done in each step (except for the first and last) is based on the previous step and is a prerec 
the work In the next step. However, the goal is to produce multiple instances of the desired result, and the steps are desi 
operate in parallel: while one step is perfomied on one instance of the result, the preceding step can be perfomned on thi 
instance of the result. 

An example of the pipelining model is an automobile assembly line, Each step or stage in the assembly line is continual!; 
receiving the product of the previous stage's work, perfonnlng its assigned work, and passing the product along to the n€ 

In a multithreaded program that reflects the pipelining model, each thread executes a step in the task. Figure 1-5 shows 
performed by three threads in a pipelining model. 

Figure 1-5 Pipelining Model of Thread Operation 
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1 ,4.4 Combination of Functional Models 

If the task that your program perfomns is complex, you might find it appropriate to organize it as a combination of the fum 
models previously described. For example, a program could follow the pipelining model, but with one or more steps perf( 
set of threads that follow a woric crew model. In addition, threads could be assigned to a wortc cirew by taking a task from 
queue and deciding (based on the task characteristics) which threads are needed for the wortc crew. 
1.5 Potential Issues for Multithreaded Programs 



When you design and code a multithreaded prograni. you must accommodate or eliminate, as appropriate, each of the f< 
issues: 



Program complexity \s the most significant issue to consider in any multithreaded programming effort. Although u: 
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can simplify the coding and designing of a program, a certain level of expertise is required to be sure that the des 
synchronization and interplay among threads Is appropriate and correctly specified. This level of expertise Is high 
required to design most single-threaded programs. 

• Dependence upon other nonreentrant software means that your multithreaded program calls a routine or library tl 
equipped to deal with threads. Given this dependence, your program must use the DECthreads global lock to pre 
conflicts with other threads that use the same nonreentrant routine or library. Section 3.9 presents multithreaded 
programming techniques for managing dependencies upon other nonreentrant software. 

• Due to programrriing errors, race conditions in the program's behavior can cause unpredictable and erroneous pr 
behavior. Similarly, deadlocks can cause two or more threads to be blocked from executing indefinitely. Section 3 
discusses race conditions In more detail, and Section 3.6.3 discusses deadlocks. 

• Priority inversion prevents high-priority threads from executing when Interdependencles exist among three or mor 
different priorities. Section 3.5.2 discusses techniques for avoiding priority inversion. 
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Chapter 6 

Kernel Threads Process Structure 

This chapter describes the components that make up a kernel threads process. This chapter contains the following secti* 

• Section 6.1 describes the process control block (PCB) and the process header (PHD). 

• Section 6.2 describes the kernel thread block (KTB). 

• Section 6.3 describes the process identifier (PID). 

• Section 6.4 describes the process status bits. 

For more infomiation about kernel threads features, see the OpenVMS Alpha Version 7.0 Bookreader version of the Ope 
Programming Concepts Manual. 

6.1 Process Control Blocks (PCBs) and Process Headers (PHDs) 

Two primary data structures exist in the OpenVMS executive that describe the context of a process: 

• Software process control block (PCB) 

• Process header (PHD) 

The PCB contains fields that identify the process to the system. The PCB comprises contexts that pertain to quotas and 
scheduling state, privileges. AST queues, and identifiers. In general, any Information that must be resident at all times is 
Therefore, the PCB is allocated from nonpaged pool. 

The PHD contains fields that pertain to a process's virtual address space. The PHD consists of the working set list, and t 
section table. The PHD also contains the hardware process control block (HWPCB), and a floating point register save art 
HWPCB contains the hardware execution context of the process. The PHD is allocated as part of a balance set slot, and 
outswapped. 

6.1 .1 Effect of a Multithreaded Process on the PCB and PHD 

With multiple execution contexts within the same process, the multiple threads of execution all share the same address £ 
have some Independent software and hardware context. This change to a multithreaded process impacts the PCB and F 
structures and any code that references them. 

Before the implementation of kernel threads, the PCB contained much context that was per process. With the introductio 
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threads of execution, much context becomes per thread. To accommodate per-thread context, a new data structure— the 
thread block (KTB)— is created, with the per-thread context removed from the PCB. However, the PCB continues to con 
common to all threads, such as quotas and limits. The new per-kemel thread structure contains the scheduling state, pri( 
the AST queues. 

The PHD contains the HWPCB, which gives a process its single execution context. The HWPCB remains in the PHD; thi 
is used by a process when it is first created. This execution context Is also called the initial thread. A single threaded pro* 
only this one execution context. Since all threads in a process share the same address space, the PHD continues to des 
entire virtual memeory layout of the process. 

A new structure, the floating-point registers and execution data (FRED) block, contains the hardware context for newly ci 
kernel threads. 

6.2 Kernel Thread Blocks (KTBs) 

The kemel thread block (KTB) Is a new per-kemel thread data structure. The KTB contains all per-thread context moved 
PCB. The KTB is the basic unit of scheduling, a role previously performed by the PCB. and is the data structure placed ir 
scheduling state queues. Since the KTB is the logical extension of the PCB. the SCHED spinlock synchronizes access tc 
and the PCB. 

Typically, the number of KTBs a multithreaded process has, matches the number of CPUs on the system. Actually, the n 
KTBs is limited by the value of the system parameter MULTITHREAD. If MULTITHREAD is zero, the OpenVMS kemel s 
disabled. With kemel threads disabled, user-level threading is still possible with DECthreads. The environment is identic^ 
OpenVMS environment prior to this release that implements kemel threads. If MULTITHREAD is nonzero, it represents t 
maximum number of execution contexts or kemel threads that a process can own, including the initial one. 

In reality the KTB Is not an independent structure from the PCB. Both the PCB and KTB are defined as sparse structures 
of the PCB that move Xo the KTB retain their original PCB offsets in the KTB. In the PCB, these fields are unused. In effe 
stifuctures are overiaid, the result is the PCB as it currently exists with new fields appended at the end. The PCB and KTI 
initial thread occupy the same block of nonpaged pool; therefore, the KTB address for the initial thread is the same as fo 

6.2.1 KTB Vector 

When a process becomes multithreaded, a vector similar to the PCB vector is created in pool. This vector contains the lit 
addresses for the kemel thread blocks in use by the process. The KTB vector entries are reused as kemel threads are ci 
deleted. An unused entry contains a zero. The vector entry number is used as a kemel thread ID. The first entry always < 
address of the KTB for the initial thread, which is by definition kemel thread ID zero. The kemel thread ID is used to builc 
PIDs for the individual kernel threads. Section 6.3.1 describes PID changes for kernel threads. 

To implement these changes, the following four new fields have been added to the PCB: 

• PCB$L_KTBVEC 

• PCB$LJNITIAL_KTB 

• PCB$L_KT_COUNT 

• PCB$L_KT_HIGH 

The PCB$LJNITIAL_KTB field actually overiays the new KTB$L_PCB field. For a single threaded process. PCB$L_KTE 
initialized to contain the address of PCB$LJNITIAL_KTB. The PCB$L_INITIAL_KTB always contains the address of the 
thread's KTB. As a process transitions from being single threaded to multithreaded and back, PCB$L_KTBVEC Is update 
to either the KTB vector in pool or PCB$LJNITIAL_KTB. 

The PCB$L_KT_COUNT field counts the valid entries In the KTB vector. The PCB$L_KT_HIGH field gives the highest vi 
number in use. 

6.2.2 Floating-Point Registers and Execution Data Blocks (FREDs) 

To allow for multiple execution contexts, not only are additional KTBs required to maintain the software context, but addil 
HWPCBs must be created to maintain the hardware context. Each HWPCB has allocated with It a block of 256 bytes for 
the contents of the floating-point registers across context switches. Another 128 bytes Is allocated for per-kemel thread c 
Presently, only a clone of the PHD$L_FLAGS2 field Is defined. 

the combined structure that contains the HWPCB, floating-point register save area, and per-kerhel thread data Is called 
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point registers and execution data (FRED) block. It is 512 bytes in length. These structures reside in the process's balam 
This allows the FREDs to be outswapped with the process header. On the first page allocated for FRED blocks, the first 
are reserved for the Inner-mode semaphore. 

6.2.3 Kernel Threads Region 

Much process context resides In P1 space, taking the fomn of data cells and the process stacks. Some of these data cell: 
per-kemel thread, as do the stacks. By calling the appropriate system service, a kernel thread region in PI space is initia 
contain the per-kemel thread data cells and stacks. The region begins at the boundary between PO and P1 space at add 
40000000X, and it grows toward higher addresses and the initial thread's user stack. The region is divided into per-keme 
areas. Each area contains pages for data cells and the four stacks. 

6.2.4 Per-Kemel Thread Stacks 

A process is created with four stacks; each access mode has one stack. All four of these stacks are located in PI space, 
are either fixed, detenmined by a SYSGEN parameter, or expandable. The parameter KSTACKPAGES controls the size 
kemel stack. This parameter continues to control all kernel stack sizes. Including those created for new execution contex 
executive stack Is a fixed size of two pages; with kemel threads Implementation, the executive stack for new execution o 
continues to be two pages In size. The supervisor stack Is a fixed size of four pages; with kemel threads implementation, 
supervisor stack for new executk)n contexts Is reduced to two pages in size. 

For the user stack, a more complex situation exists. OpenVMS allocates P1 space from high to lower addresses; The us 
placed after the lowest P1 space address allocated. This allows the user stack to expand on demand toward PO space. \ 
introduction of multiple sets of stacks, the locations of these stacks impose a limit on the size of each area In which they 
With the Implementation of kemel threads, the user stack is no longer boundless. The initial user stack remains semibou 
still grows.toward PO space, but the limit is the per-kemel thread region Instead of PO space. 
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Introduction to Multithreading 
Programming Topics 



Multithreading is a technique generally used to improve performance and enhance the perceived 
responsiveness of applications. Especially on computers with more than one processor, multithreading 
can allow a program to execute multiple pieces of code simultaneously. Of course, multithreading 
also has its dangers. Protecting critical data structures and synchronizing the efforts of multiple 
threads requires careful thought and consideration. 

This dociunent introduces you to the basic concepts associated with creating a multithreaded 
application. It also provides examples and guidance for how to use the multithreading technologies 
in Mac OS X. 




Organization of This Document 



The various issues involved in building a multithreaded application are covered in the following 
articles: 

:■ "Threads" (page 11) describes what threads are and why they are useful. 

■ "Thread Packages" (page 15) describes the advantages and disadvantages of the different threads 
packages in Mac OS X 

■ "Synchroruzation and Locking" (page 19) describes the technologies available for synchronizing 
and protecting critical regions of code. 

m "Thread Commimication" (page 23) discusses the technologies available for communicating 
between threads. 

!■ "Thread Safety Guidelines" (page 27) offers guidance on how to avoid many of the problems 
that arise with multiple threads of execution. 

■ "Cocoa Thread Safety" (page 31) describes safety issues to be aware of when using Cocoa objects 
in threads. 

■ "Core Foundation Thread Safety" (page 37) describes safety issues to be aware of when using 
Core Foundation objects in threads. 
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■ "Creating Threads in Cocoa" (page 39) demonstrates how to create a new thread in a Cocoa 
application. 

■ "Creating Threads in Carbon" (page 43) shows how to create a new thread in a Carbon application. 

■ "Using Locks in Cocoa" (page 47) demonstrates the use of Cocoa locking techniques. 

■ "Using POSIX Thread Locks" (page 53) demonstrates the use of pthread mutexes and conditions. 

■ "Communicating With Mach Ports" (page 55) demonstrates the use of Mach ports to conrununicate 
between Carbon and Cocoa threads. 

■ "Communicating With Distributed Objects" (page 61) demonstrates the use of Distributed Objects 
to commimicate between Cocoa threads. 
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Threads 



In Mac OS X, each process comprises one or more threads. A thread is a stream of execution that runs 
code for the process. Multiple threads may execute the same code, but they do so independently of 
other threads. Each thread has its own execution stack and is capable of independent ii^ut and output. 
However, all threads share the same virtual memory address space and have the same access rights 
as the parent process. 

Threads let your program perform multiple tasks in parallel. For example, you can use threads to 
perform several, lengthy calculations while your user interface continues to respond to user commands. 
You could also use threads to divide a large job into several smaller jobs. 

On multiprocessor systems, each processor can execute the code for a different thread. This parallel 
execution can lead to tremendous performance gains for your program and for the system as a whole. 

A process has only one thread irutially. That thread can spawn additional threads using any of the 
available threading APIs described in "Thread Packages" (page 15). The threading API you choose 
is usually driven by the programming environment you are using (Carbon, Cocoa, Darwin, and so 
on) and your performance needs. 




Tliread Terminology Issues 



If you are familiar with Carbon's Multiprocessor Services API, then you are probably used to seeing 
the term "task" to represent a separate thread of execution. The use of the term "task" in the 
Multiprocessor Services API was intended to distinguish from the terminology used by the Carbon 
Thread Manager API. The term "task" may also be familiar to developers who work on UNIX systems, 
where the term indicates a running process. 

In practical terms, a Multiprocessor Services task is equivalent to a preemptively scheduled thread 
in Mac OS X. In fact, with one exception, all threads in Mac OS X are scheduled preemptively. Only 
the Carbon Thread Manager uses a cooperative scheme for scheduling threads. This scheme ensures 
that applications written for earlier versions of Mac OS will not break when ported directly to Mac 
OSX. 
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This document provides a conceptual mapping of thread function by 

calls between four implementations: HP-UX threads (based on David Graves, HP 

POSIX and X/Open). Solaris threads. POSIX threads on Solaris. 

and NT proprietary threads. 

» Overview of implementations 
» Synchronization 
» Emulation partners 

Overview of implementations 

POSIX threads are more portable, establish characteristics for each thread according to c 
attribute objects, implement thread cancellation, enforce scheduling algorithms, and allow 
up handlers for fork calls. 

Solaris threads can be suspended and continued, implement optimized reader/writer locki 
Increase the concurrency, and implement daemon threads, for whose demise the process 
wait. 

X/Open threads extend the POSIX standard to include many of the capabilities of Solaris 
such as suspend, continue, and optimized reader/writer locking. 

The POSIX implementations on HP-UX and Solaris are very similar. However. HP-UX pth 
include the X/Open threads calls (frequently similar to proprietary Solaris threads calls). A 
pthreads include non-portable functions (with names ending in _np ) which sometimes rej 
proprietary Solaris or NT threads calls. Thus, HP-UX pthreads are neariy a superset of PC 
threads. Solaris threads, and NT threads. 

Synchronization 

Since threads run concunrently and share resources, synchronization mechanisms are re( 
provide mutually exclusive access to shared data. The four mechanisms defined In threac 
are: mutexes, condition variables, reader/writer locking (frequent-read occasional-write). t 
semaphores. Each are covered in the tables below. 

Solaris threads and the HP-UX threads implement all four mechanisms. The Solaris POSI 
implements all but reader/writer locking. NT implements ail four, but there is not a direct n 
UNIX® functions. For example, multiple reader single writer locking is a feature of IStrean 
which is not the same as Reader/Writer locks in POSIX threads. 

Thread call Implementations 



These notes correspond to the table that follows. 



» HP Technology 
-^^^ Forum 

October U'lO 
Orlando, Floridq, 



Functions mariced with an asterisk (*) were developed by X/Open; they are implenr 



http://devresource.hp.com/drc/STK/ docs/refs/sol_threads.jsp printed September 14, 2005 



HP-UX version of pthreads, but not in the Solaris version. 

Functions marked with a tilde (-) provide functionality similar to. but not the same ; 

functions. 

HP-UX function names ending in _np are Not Portable to other UNIX platfomns. F( 
the HP-UX pthread_resiiine_np exactly matches NT's ResumeThread 
(incrementing/decrementing suspension count), while the HP-UX pthread_cont. 
matches Solaris* thr_continue function. 



Creation 

POSIX and X/Open 
pthread_create 

pthread_create(start_func) 

pthread_attrjnit 

pthread_attr_destroy 

pthread_attr_getdetachstate 

pthread_attr_getguardsize* 

pthread_attr_getinheiitsched 

pthread_attr__getschedparam 

pthread_attr_getschedpolicy 

pthread_attr_getstackaddr 

pthread„attr^etstacksize 

pthread_attr_c|etscope 

pth read_attr_setdetachstate 

pthread_attr_setguardsize* 

pthread_attr_setinheritsched 

pthread_attr_setschedparam 

.pthread_attr_setschedpolicy 

pthread_attr_setstackaddr 

.pthread_attr_setstacksize 

pthread_default_stacksize_np 
pthread_attr_setscope 
pthread_attr_getprocessor_np 
.pthread_attr_setprocessor_np 



Solaris 
thr_create 
thr_create(daemon) 
thr_create(start) 



NT 

CreateThread 

CreateRemoteThrea 

ThreadProc 



thr min stack 



SetTh read Ideal Proc€ 



isl Printable version 



Exit 

POSIX and X/Open 
pthread_exit 
pthreadjoih 
pthread„detach 



Solaris 
thr„exit 
thrjoin 



NT 

ExitThread 
GetExitCodeThread- 
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DECLARATION OF DR. DAVID R LEVINE 



I, David R. Levine, declare as follows. 

1 . I hold the following degrees: 

• Ph.D., Computer Science, Stanford University (1973) 

• M.S., Computer Science, Stanford University (1968) 

• B.A., Physics, Harvard University (1965) 

2. My professional experience includes: 

• 38 years working as a computer scientist in a variety of areas, including operating 
systems, progranmiing language design, compilers and optimization, and 
instruction set architecture design 

• Assistant Professor of Computer Science at Rutgers University 

• Assistant Professor of Computer Science at Boston College 

• Adjunct Lecturer in Computer Science at the University of Massachusetts 

• Co-inventor on U.S. Patent No. 6,332,188 for features in the instruction set 
architecture of Analog Devices' TigerSHARC processor 

• Member of the ANSI Fortran Language Standards committee (X3J3) 
(representing Hewlett-Packard Company), and also the ANSI Parallel Computing 
Committee (X3H5), both committees relating to parallel execution 

• At Stanford, I was one of four key designer/implementers of a multi-user 
timesharing system. One of my specific responsibilities involved the design, 
implementation and maintenance of interrupt handlers, and their interaction with 
general process scheduling. 
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• I constructed several large programs using the SIMULA-67 language, which has 
support for independent threads of control as an inherent part of the language. 

• I implemented the parallel-processing portion of the "test translator" (compiler- 
interpreter combination) for one of the first implementations of the Ada 
programming language, using the Simula multi -threading capabilities in the 
interpreter to provide an effective simulation'of multiple processes. 

• I am currently working on an operating system project, with responsibilities in the 
area of interrupt and exception handlers. We're working with the Java language, 
which provides "threads" as a basic capability. My work involves both the use of 
Java threads, and the crafting of the underlying support that makes them work. 

3. In preparing this declaration, I have reviewed the following portions of the 
prosecution history for application serial no. 09/626,325, and other materials: 

• Office Actions of 10/27/2004, 7/19/2005 and 10/14/2005, and Mr. Boundy's 
papers of 4/27/2005 and 9/15/2005 

• The specification of this application 

• The paper captioned "Petition to Technology Center SPRE" of 9/15/05, including 
its Exhibits A-K 

• Additional discussions of "threads" from the Internet that I found using the 
"Google" search engine 

• U.S. Pat. No. 5,774,686, Hammond, Method and Apparatus for Providing Two 
System Architectures in a Processor 

• The online version of MPEP §§ 2111-2111.01, describing the rules of claim 
interpretation, including the principles of "broadest reasonable interpretation 
consistent with the specification," "consistent with the interpretation that those 
skilled in the art would reach," and the "ordinary and customary meaning of a 
claim term is the meaning that the term would have to a person of ordinary skill in 
the art in question at the time of the invention" 

• The online version of MPEP § 21 12 relating to "inherency" 

• Excerpts from § 1 1.04, "Amendments - New Matter" from the Chisum "Patents" 
treatise 

4. I also rely on my personal knowledge in the art, and the plain meaning given 
terms in the art. 
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I. Derinition of the Term "Thread" 

A. Examiner Ellis' View is Incompatible with the Ordinary and Customary 
Meaning in the Art 

5. The term "thread " is a well-established term of art in the arts of programming 
language systems, operating systems, and processor architectures.^ Without attempting to give a 
full definition of the term "thread," I note that the "broadest reasonable" "ordinary and 
customary meaning" of the term "thread" "that those skilled in the art would reach," that the 
term "would have to a person of ordinary skill in the art in question at the time of the invention," 
refers to one of one or more concurrent flows of control within a process, program or address 
space. Concurrency, and the related concepts of parallelism and independent scheduling, are the 
basic "reason for being" of threads. I do not believe that anyone applying the "broadest 
reasonable meaning of the word [thread] in [its] ordinary usage as [it] would be understood by 
one of ordinary skill in the art" could omit a consideration of concurrency. 

6. Based on my observations of new college graduates that I have worked with, and 
the University of California San Diego and Carnegie-Mellon materials provided as Exhibits D 
and E, I believe that the "ordinary and customary meaning" of threads that I described in | 5 was 
established among undergraduate computer science curricula as of 1999. My direct experience is 
that the "ordinary and customary meaning" of threads that I described in ^ 5 was established 
among those practicing in the art well before this date, and my experience is confirmed by 
Exhibits A-K.^ 

7. The various references in Exhibits A-K to "independent scheduling," 
"parallelism," and "overlap" are closely related to "concurrency." These references demonstrate 
that concurrency is an essential element of any reasonable "ordinary and customary meaning" of 
"thread" that would be understood by "a person of ordinary skill in the art in question at the time 
of the invention." Some of the Exhibits are intended more to indicate the general concept of 



' As noted in Exhibits D-K, the precise definition of "thread" varies somewhat vendor-to- vendor, 
but is consistent in the respects discussed in f 5. 

^ Note that the above definitions allow for single-thread processes, in the simplest case. 
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"thread" to the non-specialist than to serve as precise definitions, but each is consistent in that it 
focuses on concurrency. 

B. Examiner Ellis' Interpretation is Unreasonably Overbroad 

8. In contrast, the two Office Actions I reviewed state inadequate, unreasonable, and 
misleadingly overbroad definitions. 

9. Interestingly, the Yahoo! definition cited by the Examiner (Action of 10/27/2004, 
page 2) is reasonably correct. It seems rather incongruous that the Examiner refused to accept 
his own choice of dictionary definition in subsequent papers. 

10. The Microsoft Dictionary definitions, and Examiner Ellis' interpretation of them, 
are simplistic and overbroad. The definition of "thread" applies not only to threads but to many 
other constructs that can form part of a computer program. The definition thus fails to convey 
any useful information, let alone a reasonable definition. In particular, the notion of concurrency 
is totally missing from the Microsoft Dictionary definition. The Microsoft Dictionary definition 
would be viewed as unreasonable and incorrect by those of ordinary skill. 

11. The Examiner's definition for "process" is even more severely flawed. This 
definition is so vague and overbroad as to be totally useless, as it clearly admits constructs that 
would not be considered to be a "process." It would be viewed as unreasonable and incorrect by 
those of ordinary skill. 

12. Starting with inadequate definitions, it is not surprising that the Examiner draws 
unwarranted conclusions; and that his comments are self-contradictory. 

C. The Definitions of "Thread" and "Process" Used by Examiner Ellis are 
Inconsistent With the Specification 

13. The "ordinary and customary meaning" of "threads" that I described in ^ 5 is the 
meaning clearly intended in the specification. The definition suggested by Examiner Ellis is 
inconsistent with the use in claims 31 and 37 themselves, and several sentences and paragraphs 
of the specification, that juxtapose the words "thread," "process," and "handler" in ways that are 
inconsistent with the interblurring suggested by Examiner Ellis. This would be true even without 
the amendment to the specification of 4/27/2005. 
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D. The Term "Thread" Has No Exact Synonym, and Therefore Departure from 
the "Ordinary and Customary Meaning" is Unreasonable and Incorrect 

14. To the extent that the Office Action suggests (e.g.. Action of 10/27/2004, 
paragraph at page 2, lines 5-7) that the claims should be redrafted to "limit the definition of tread 
[sic]" to only the ordinary and customary meaning of the word "thread" but to exclude the 
unreasonable meanings extrapolated in the Office Action, the Office Action asks the impossible. 
To my knowledge, there is no other term that has a recognized definition that has the exact scope 
as the ordinary and customary meaning of the term "thread.""^ If the meaning of the word 
"thread" is distorted as proposed in the Office Actions, there is no other word available to take its 
place. 

11. Examiner Ellis "Fundamentally Misunderstands" Elementary Principles of 
Computer Operations and Operating Systems 

15. Paragraph 12 of the Examiner's Action of 10/14/2005 refers to a "fundamental 
misunderstanding." The Examiner's reasoning demonstrates little understanding of basic 
principles, concepts that would certainly be part of an undergraduate or graduate curriculum, and 
certainly are well understood by, and part of the ordinary usage of, practitioners working in the 
area of programming language systems, operating systems, and processor architectures. 

16. Paragraphs 12 and 13 of the Examiner's paper of 10/14/2005 read as follows: 

12. Applicant further argues that all the definitions he supplies either state 
concurrency, or inherently require concurrency in the definition of thread. However, 
applicant is incorrect in that argument. While several of applicant's definitions do state a 
concurrency requirement as part of the definition of "thread", other definitions make no 
such requirement. For example, applicant's own definition from The Authoritative 
Dictionary of IEEE Standards Terms, 7th ed. (2000) (Exhibit A) includes no such 
requirement for concurrency in the definition of threads. Applicant relies upon the 
statement "scheduling priority and policy" in the BEEE definition of "thread" to imply an 
inherent concurrency to "thread". However, this reliance exposes a fundamental 
misunderstanding of the meaning of "concurrency" and "scheduling". 

concurrent 1 : operating or occurring at the same time. 2 a: convergent: specf. 
meeting or intersecting at a point b: running parallel 3: acting in conjunction 4: 
exercised over the same matter or area by two different authorities (Webster's 
Ninth New Collegiate Dictionary, 1990) 

concurrent: pertaining to the occurrence of two or more activities within a given 
interval fo [sic] time (B) cf consecutive, sequential, simultaneous (Dictionary 



^ "Lightweight process" is close, but not an exact synonym. 
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of Computers, Information Processing & Telecommunications, 2nd edition, 
Jerry M. Rosenberg, editor, 1987) 

13. As seen from the above, concurrent means perfomning a plurality of actions 
at the same time, or in parallel. If, as applicant asserts, the statement "scheduling priority 
and policy" inherently meant concurrent (meaning required to be performed at the same 
time or in parallel) then because the tasks were being performed in parallel at the same 
time, there would be no need to "schedule" the tasks. If everything is performed in 
parallel at the same time, the system would simply perform all the tasks in parallel. By 
"scheduling" the tasks, as indicated by the EEEE dictionary, the dictionary has in fact 
indicated against an inherent (or required) concurrency, because the need to "schedule" 
tasks means that they can not all be performed in parallel. 

17. The Examiner's argument badly misses the point. 

18. For example, concurrency does not require "performing a plurality of actions at 
the same time." As Examiner Ellis' own quote from the Rosenberg Dictionary explains, 
"concurrency" merely provides the illusion of simultaneity by allowing several things to occur in 
an interval of time that is short compared to human perception. Computer processors execute 
instructions sequentially,"^ but may rapidly alternate among threads at a fine granularity. That 
alternation is the most classical form of "concurrency." The Rosenberg Dictionary specifically 
contrasts ("cf.") "concurrent" to the related, but somewhat different word "simultaneous." Even 
if one accepted the Microsoft Computer dictionary at face value. Examiner Ellis understanding is 
wrong, both at a technical level, and at the level of careful reading. 

19. For an operating system or programming language system to provide "threads" as 
a capability, the system must contain various capabilities to manage the threads' interaction. For 
example, the system must provide a capability to put an executing thread into a suspended state 
and allow some other thread to use the processing resource. This is called scheduling. Those of 
ordinary skill understand that a commercially reasonable implementation of threads necessarily 
implies the existence of a concurrent progranraiing model (even if not explicitly multi-processor 
parallelism), with concomitant tools including a scheduler and synchronization. Even if one 
accepted the Microsoft Computer dictionary, the "fundamental misunderstanding" of notions 



^ Even recent innovations such as "superscalar" processors include elaborate interlocks that 
force instructions to be executed as if they were executed sequentially, even where there is some actual 
simultaneity. 
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such as "scheduling," "synchronization," and "concurrency" or "parallelism" displayed in the 
Office Action is troubling. 

20. Examiner Ellis' statement that "everything is performed in parallel at the same 
time" bears no relation to actual art or practice. In most computers, this is quite impossible. 
None of the materials I reviewed, including the Microsoft Dictionary, support such a statement. 

21. Webster's Ninth New Collegiate Dictionary is not a technical dictionary. Mr. 
Boundy explained to me that non-technical dictionaries are deprecated as a source of 
interpretation for technical terms, and I thus do not consider the Webster's definition. 

22. Examiner Ellis' statement in his paper of 10/14/2005 % 9 bears comment. 
Examiner Ellis says "If applicant has a complaint with the definition of thread published by 
Microsoft, then applicant's arguments should be directed to Microsoft, not to the US Patent 
Office." I agree with Examiner Ellis' concession, that the Microsoft Dictionary is in error, and 
needs to be corrected. In my opinion, the Microsoft Dictionary is not considered as authoritative. 
Other sources, such as the documentation for real programs, and definitions taken from technical 
standards that control billions of dollars of industry investment (such as the IEEE Dictionary 
definitions and the standards from which those definitions are taken), and the vendor 
documentation discussed above, are authoritative (when considered together with their 
supporting materials and in their proper context). My quarrel is with Examiner Ellis' blind 
allegiance to the Microsoft Dictionary as an authoritative source, and its uncritical adoption of 
definitions that anyone of ordinary skill would recognize as unreasonable over-simplifications. 

III. The Theory of Operation of Processes and Threads Was Known in the Art 

23. Well before 1999, essentially all conrmiercial operating systems provided support 
for the operation of multiple processes, certainly within the operating system itself, and generally 
as a feature available to user programs. 

24. Based on my observations of new graduates, and the University of California San 
Diego and Carnegie-Mellon materials provided as Exhibits D and E, and my own interaction 
with professionals in the field, I believe that threads were reasonably common subject matter for 
undergraduate computer science curricula as of 1999, and that undergraduates were taught the 
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theory of operation of threads. My direct experience is that the definition of threads was known 
by those practicing in the art well before this date, and my experience is confirmed by Exhibits 
A-K. Undergraduates and practitioners understand the term consistent with my understanding 
stated above in ^ 5, above, and understand the theory of how to use threads, as explained in 
Exhibits D-K. 

25. As of January 1999, many commercial operating systems, and many 
programming language systems, provided implementations of threads. Knowledge of the 
implementation and use of multiple processes in general, and threads specifically, were both 
well-established in the art. 

IV. The Amendment Is Not "New Matter" 

26. Mr. Boundy provided excerpts from the Chisum treatise relating to "new matter" 
to explain the concept of "new matter" to me, and I apply that understanding in the following 
paragraphs. 

27. The examiner objects to this sentence: 

The terms "process" and "thread" are used herein in their ordinary and customary, though 
formal, senses, as actually used in the programming language systems, operating systems, 
and processor architecture arts. 

In my opinion as one skilled in the relevant arts, this sentence merely explicitly states a fact that 
was inherent in the specification and the claims, that the terms "process" and "thread" are used in 
the specification and claims in their ordinary and customary, though formal, senses, as those 
terms are actually used in the arts of programming language systems, operating systems, and 
processor architecture. 

28. The examiner objects to this sentence: 

Generally, a "process" is a unit of processor scheduling and protection, each with an 
associated data structure (or set of data structures) that, in most implementations, holds 
machine register values and other context associated with the process. 

In my opinion as one skilled in the relevant arts, this sentence is clearly merely an explicit 

statement of the ordinary understanding in the art, and the theory of operation for processes as 

that theory is ordinarily understood in the art. This material is inherent in the application 

specification, even without the amendment. 
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29. The examiner objects to this sentence: 

The process data structures, and thus the processes of a computer, are usually under the 
management of an operating system, usually the operating system's scheduler. 

In my opinion as one skilled in the relevant arts, this sentence is merely an explicit statement of 

the theory of operation. This material is inherent in the application specification, even without 

the amendment. 

30. The examiner objects to this sentence: 
Generally, a "thread" is a flow of control within a process. 

In my opinion as one skilled in the relevant arts, this sentence is merely an explicit statement of 
the understanding of one of ordinary skill. This material is inherent in the application 
specification, even without the amendment. 

3 1 . The examiner objects to this sentence: 

Each thread has an associated data structure (or set of data structures) that, in most 
implementations, hold machine register values (usually different than the registers 
associated with a process) and other context associated with the thread. 

In my opinion as one skilled in the relevant arts, this sentence is merely an explicit statement of 

theory of operation. This material is inherent in the application specification, even without the 

amendment. 

32. The examiner objects to this sentence: 

The thread data structures, and thus the threads of a process, are usually managed either 
by an operating system or other run time system, to permit the thread to be scheduled 
independently of and concurrently with other threads of the same process. 

In my opinion as one skilled in the relevant arts, this sentence is merely an explicit statement of 

theory of operation. This material is inherent in the application specification, even without the 

amendment. 

V. The Examiner's Understanding of the Relationship Between "Threads" and 
"Handlers" is Wrong 

33. Those of ordinary skill in the relevant arts understand the terms "thread" and 
"exception handler" to refer to two quite different things. Examiner Ellis' implication that these 
two concepts may be equated conveys a fundamental understanding about the underlying 
concepts. 
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34. An exception handler is a set of computer instructions invoked in response to the 
occurrence of an exception. The handler "handles" the exception and returns control to the 
interrupted program. Execution of an exception handler is reasonably analogous to a procedure 
call - the program that raised the exception must be suspended until the handler completes. 
Indeed, exception handling is often presented as a variant of procedure call. Leaving room for 
unconventional or artificially-constructed situations that are not before me today, a handler in the 
prior art never executes "independently of and concurrently with" (to use the Office Action's 
definition from Yahoo!) the thread that raised the exception. Any assertion that the two terms 
are somehow interchangeable is wrong. 

35. In contrast, a thread is a unit for organizing and independently executing a set of 
operations. In most cases, a thread executes under control of a scheduler, mediated by whatever 
synchronization operations it needs for interaction with its parent and/or other threads. 

36. An exception handler per se cannot serve as a thread. 

37. A thread could host an exception handler, in an unusual situation. However, that 
unusual situation would require special handling, as described in the application's specification. 

38. I see no reason to believe that Hammond is such an exceptional case, or that his 
exception handlers would be implemented using threads. 

VI. Conclusion 

39. I express no opinion on any issue not expressly set forth above. 
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40. I declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that wiUfiil false statements and the like so made are 
punishable by fine or imprisonment, or both, under 18 U.S.C. § 1001 and that such willful false 
statements may jeopardize the validity of the application or any patent issuing thereon. 



Respectfully submitted. 



Dated: 





Dr. David R. Levine 
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